5 ms·
Time is a PITA to normalize between frontends and backends, but not an overly arduous task. I wonder what's preventing them from know what the users preferred f
by kodah 3y ago
Time is a PITA to normalize between frontends and backends, but not an overly arduous task. I wonder what's preventing them from know what the users preferred format is.
Anecdotally, I worked for a British company that used YY/MM/DD and it regularly caused reliability issues during operations. Of course, they responded with, "What's wrong with the date? It's correct." Yes - correct, but not accessible especially operationally so. If you want to take advantage of a global userbase or workforce be prepared to have the tax of these kinds of features being necessary.
- benoliver999 3y agoThese days I display it as "12 July 2023" to avoid confusion.
- wizofaus 3y agoHow would that not be confusing to non-English speakers? Or even to English speakers when it inevitably gets truncated trying to fit "12 September 2023" in a field originally designed to show 6 or 8 digits...
- deleted 3y ago[deleted]
- rdtsc 3y agoA slight improvement might have been to use four digits for the year. Then it’s a bit less likely to be interpreted ambiguously.
- Moru 3y agoNaturally they had problems if they wrote it YY/MM/DD. It's not a correct way of formatting the ISO 8601 date. It's supposed to be YY-MM-DD. If you use slashes between them it can be just about any format but if it's minuses it's YMD.
- dabluecaboose 3y agoISO 8601 specifies a 4-digit year for this reason. It's not YY-MM-DD, it's YYYY-MM-DD.
- out_of_protocol 3y ago*YYYY
- einherjae 3y agoTo be pedantic: YYYY-MM-DD The full year is required to make it clear that 23-12-10 isn’t the day before X-mas eve in 2010
- Groxx 3y agoEmail requires you to store something and it's perpetually buggy to infer, but with an interactive client the answer is pretty much always "store unix, localize at display-time on the device". Any other way means risking disagreement with the device settings, and that format is BY FAR what people expect when they use their device.
- crooked-v 3y ago> store unix Heck no. That means your date changes if the instant<->date mapping changes (for example, adding a leap second, or your country changes their time zones). If it's a plain date, store it as an ISO 8601 date (for example, "2023-12-30"), or equivalent plain date format (such as Postgres DATE).
- Groxx 3y agoUnix -> "include leap seconds and time zone changes" conversion is extremely well studied and well supported. Literally every major operating system does it as the primary way to display dates - that's what the time-zone database in ICU/CLDR exists to solve. And those changes may affect which "day" you consider something to have occurred on, date alone is frequently not good enough.
- LinAGKar 3y agoNo, leap seconds are included in Unix time, so adding leap seconds won't change how it's converted into a human-readable date. To store it without leap seconds you would use TAI time. Anyway, sure, for scheduling something in a calendar you would want something timezone-aware. But not for storing timestamps. If a country changes what time zone they used it the past (not sure why they would ever do that) that shouldn't move the time the objective time an event occurred at.