3 ms·
> 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
by 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.