undefined | Better HN

0 pointswilliamdclt1y ago0 comments

> you can still use the last definition of such a timezone if the date is still in the future

but that'll possibly give you an incorrect time!

If you want to store "8am in Paris on the 2026-01-01", then you store "2026-01-01T08:00:00 Europe/Paris". Great, if Paris decides to change their offset rules, that's fine.

Currently, that would be `2026-01-01T08:00:00+01:00` but if Paris decide to ditch DST, it could become `2026-01-01T08:00:00+00:00`. All good, you stored a timezone rather than an offset, so you're decoupled from the timezone->offset changes.

But if tomorrow `Europe/Paris` cease to exist, and is replaced with Europe/NewNewYork? The last definition of Europe/Paris would make this date `2026-01-01T08:00:00+01:00`, but if Europe/NewNewYork ditched DST then it wouldn't be 8am for the people living there, it'd be 7am.

You're decoupled from the timezone->offset changes, but not from location->timezone changes.

0 comments

jitl1y ago

The reason the zones use city names is because city identity is far more stable than national or regional borders. Still, the system can gracefully handle deprecation of a zone name. If Paris is renamed NewNewYork by edict of some new global despot, the IANA will just alias the two names together.

See https://github.com/eggert/tz/blob/main/backward for all the deprecated zones.

j / k navigate · click thread line to collapse