The UK skipped 11 days in 1752. There were riots.

In the same way that an hour is skipped in many places at the beginning of Daylight Saving Time every year (and the offset changes, e.g. from UTC–5 to UTC–4),

on this particular instant, in Iceland, 28 minutes were skipped because Iceland changed from the offset of Reykjavik’s mean solar time, rounded to the nearest minute (UTC–1:28) to the offset of Reykjavik’s mean solar time, rounded to the nearest hour (UTC–1).

So only from that moment on, Iceland was using UTC–1.

That's how Temporal works:

    >> zdt = Temporal.ZonedDateTime.from("2024-03-09T17:00-05[US/Eastern]")
    >> zdt.add("P1d").toString()
    "2024-03-10T17:00:00-04:00[US/Eastern]"
    >> zdt.add("PT24h").toString()
    "2024-03-10T18:00:00-04:00[US/Eastern]"

If you don't have the time zone and instead just an offset, then Temporal can't do this:

    >> zdt = Temporal.ZonedDateTime.from("2024-03-09T17:00-05[-05]")
    >> zdt.add("P1d").toString()
    "2024-03-10T17:00:00-05:00[-05:00]"
    >> zdt.add("PT24h").toString()
    "2024-03-10T17:00:00-05:00[-05:00]"

Adding 1 day still works the same with respect to civil time but the offset is wrong since it doesn't account for the DST change. And adding 24 hours leads to a different result as well. This is one of the reasons why RFC 9557 is so important for serializing zoned datetimes when you want your arithmetic to be DST safe. Previously, to get this right, you had to include a time zone out of band somehow along with your RFC 3339 timestamp.

> most often if you want to do

most often it is "most often" that causes bugs in software. And when related to date/time it often are severe bugs. ;-)

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

As a Canadian, I would love for my timezone to be Americas/Toronto or Americas/Canada/Toronto rather than America/Toronto, but that's pretty far down my register of first world problems.

The prefered canonical name is continent-or-ocean/city-or-small-island because continents and cities are more stable than countries and country names. The America/state/city convention is the exception, not the rule.

Some timezone identifiers have changed, e.g. Asia/Calcutta to Asia/Kolkata in 2008 and Europe/Kiev to Europe/Kyiv in 2022. But the TZ DB maintainers are rather reluctant to make such changes, and require “long-time widespread use of the new city name” in English before deciding so.

The naming conventions for timezone identifiers are written out at https://ftp.iana.org/tz/tzdb-2022b/theory.html#naming

> https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen

Thanks! I was the co-champion of that proposal. Parts of it were merged into Temporal last year, and other parts are already part of the JS Internationalization (ECMA-402) specification here: https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database

What if England and Germany fight for France, half the country being occupied by Germany using `Europe/Francefurt` and the other half by England using `Europe/NewNewYork`? Then you can't know for sure how to interpret a "Europe/Paris" date without knowing the exact geographical location