4 ms·
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
by Groxx 3y ago
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.
- 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.