Hacker News Reader

Comment by kodah | Hacker News Reader

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.

View on HN

Email 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.

> 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).

Unix -> "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.

No, 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.

Naturally 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.

ISO 8601 specifies a 4-digit year for this reason. It's not YY-MM-DD, it's YYYY-MM-DD.

*YYYY

To 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

A slight improvement might have been to use four digits for the year. Then it’s a bit less likely to be interpreted ambiguously.

These days I display it as "12 July 2023" to avoid confusion.

How 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...

Reply on news.ycombinator.com