undefined | Better HN

0 pointscrooked-v2y ago0 comments

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

0 comments

2 comments · 2 top-level

LinAGKar2y ago

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.

Groxx2y ago

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.

j / k navigate · click thread line to collapse