4 ms·

+02:00 is not political. It's an offset from UTC and will be the same offset in the past and future. Europe/Paris is political. It defines that offsets change

+02:00 is not political. It's an offset from UTC and will be the same offset in the past and future. Europe/Paris is political. It defines that offsets change at certain times of the year, but that could change tomorrow, or the political boundary that the timezone applies to could split such that the person or entity needing a time in their "local" timezone finds another one needs to be picked (see various US states/counties applying/disapplying daylight savings). It's impossible to be 100% confident what the offset from UTC will be at any time in the future. You also need to be a historian to correctly apply it to times in the past - take https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland#History https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Irelan... as an example!

Cthulhu_ 2y ago
I wonder what happens when a timezone ceases to exist, e.g. what if Paris is renamed to New New York after the British take revenge and take over France.
- jitl 2y ago
  A timezone changing or being eliminated doesn’t erase the history of that timezone. So you can still use the last definition of such a timezone if the date is still in the future, or use the appropriate definition of the timezone at the time of a date marked in the past.
  - williamdclt 2y ago
    > 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.
    - jitl 2y 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 https://github.com/eggert/tz/blob/main/backward for all the deprecated zones.
- tomhallett 2y ago
  Your example of “New X” is spot on, because there was a timezone with that name, “US/Pacific-New”, which was different than “US/Pacific”. Bit of history: it was added to some timezone libraries because there was a bill in congress to add it, but it never passed. I had to fix a bug because users were getting set with that timezone and then other systems/libraries were barfing on it… https://github.com/moment/moment-timezone/issues/498 https://github.com/moment/moment-timezone/issues/498
- mason55 2y ago
  Here are a couple starting points https://medium.com/servicios-a0/on-solving-the-tzdb-changes-problem-7b9fa8f96b86 https://medium.com/servicios-a0/on-solving-the-tzdb-changes-... https://github.com/tc39/proposal-canonical-tz 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
  - justingrantjg 2y ago
    > https://github.com/tc39/proposal-canonical-tz 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 https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database
- Macha 2y ago
  Then Europe/Paris will become an alias for Europe/NewNewYork
  - williamdclt 2y ago
    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
    - JW_00000 2y ago
      If I understand [1] correctly, two new zones (or one new one and the old one) would be created in that case. E.g. if Strasbourg would be occupied by Germany in 2027, a new Europe/Strasbourg could be created which has the same rules as Europe/Paris until 2026, and the rules of Europe/Berlin as of 2027. [1] https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database -- By the way, I looked up the time zone in Crimea. > On 29 March 2014, after annexation by Russia, Crimea switched from Eastern European Time (UTC+02:00) to Moscow Time (UTC+04:00 then, subsequently changed to UTC+03:00). [2] Crimea has its own zone in the IANA database, Europe/Simferopol, which was updated in 2014 (and already existed before, as it already used Moscow time from 1994 to 1997). [3] [2] https://en.wikipedia.org/wiki/Time_in_Ukraine https://en.wikipedia.org/wiki/Time_in_Ukraine [3] https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/DSQMDSIJMAERCKJNB2LQF2OZHO5EA72H/#VJJQUQZCUDSMM2RIXBZB75IROWQT2UOF https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/DS...; https://github.com/eggert/tz/commit/bb203f1bb0b6cd4bb2b08f2560a3e564a5614c59 https://github.com/eggert/tz/commit/bb203f1bb0b6cd4bb2b08f25...; https://github.com/eggert/tz/blob/bb203f1bb0b6cd4bb2b08f2560a3e564a5614c59/europe#L2942 https://github.com/eggert/tz/blob/bb203f1bb0b6cd4bb2b08f2560...
- WorldMaker 2y ago
  https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03-2023-en https://www.icann.org/en/blogs/details/how-time-zones-are-co... Hopefully the British would be kind enough to email the TZ DB group at the IANA (tz@iana.org) a couple years in advance of the legislation to change the name so that the group can get started on collecting the DST rules for Europe/NewNewYork. Some people and devices will probably stick to Europe/Paris out of habit and/or resistance to the change, so the TZ DB would probably be unlikely to remove it, but they may point references from it to Europe/NewNewYork as the new "canonical" name. Plenty of the DB entries are just pointers to other entries already today, for one instance it was decided that America/City and Europe/City maybe is too conflicted a namespace and we see increasingly more "the canonical name is America/State/City" or "the canonical name is Europe/Country/City".
  - mikepurvis 2y ago
    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.
    - deleted 2y ago
      [deleted]
    - mjevans 2y ago
      How about something like: Sol3/CA/Toronto I'd also like all 50 state capitols (and possibly also their largest city) to exist as E.G. Sol3/US/WA-Olympia and Sol3/US/WA-Seattle (respectively to the above; I don't know Canadian provinces that well) Sol3 is a prefix for the 3rd planet (starting ordinal 1, but anything in the orbit of Sol can be Sol0) in our solar system. It's also nicely short so easy to type out in command lines. Every state _should_ have it's own TZ file, even if it's just an alias. That's a good forward compatible way of allowing the same config to work if future legislative efforts produce or remove timezones. It would also allow E.G. Arizona's non DST timezone to remain correctly configured in some future where the US finally ends the nightmare of DST forever.
phiresky 2y ago
That but also and for me more importantly it does not tell you how to add time - If you add one month of hours to a date in October, it depends on the timezone whether you will end up one hour of local time earlier or not (due to DST), because then +02:00 might be +01:00
- roywashere 2y ago
  While this is true, most often if you want to do "now plus a month" you'll mean "at the same time on the local clock", and disregarding timezone changes, while most often if you want to do "now plus four hours" you'd actually mean four real hours, and you want to calculate in the DST changes to make sure you have four actual hours in your duration
  - burntsushi 2y ago
    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.
    - btown 2y ago
      https://datatracker.ietf.org/doc/rfc9557/ https://datatracker.ietf.org/doc/rfc9557/ for folks' reference about the new [] suffix syntax. It's a really well thought out RFC: the offset, the civil time zone name, and a flag for whether that civil time zone is critical information can all be stored, and an inconsistency marked critical MUST be acted upon by the application explicitly, either by rejecting or requesting user interaction. This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I honor the absolute point in time, or do I honor the notion of 5pm?" Unfortunately, there's going to be a lot of chaos if this happens. Systems like Postgres only store the absolute point in time, normalized to UTC, despite what the name "timestamp with time zone" might imply; an application team or DBA making a decision about this might need to look at other domain-specific metadata e.g. the physical location of the associated asset to determine whether to add or remove an hour. I shudder to think about what this might imply for e.g. HIPAA protected medical systems; the impact of the ensuing bugs might be measured in lives.
tharkun__ 2y ago
Even countries that are on UTC don't save you from this. I had no idea until very recently but there is a time that simply never existed in Iceland! Wednesday January 2st 1908 00:00 clocks were turned forward 28 minutes to 00:28. So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round and one might think they are the best and easiest country to handle timezone wise. https://mm.icann.org/pipermail/tz/1993-November/009236.html https://mm.icann.org/pipermail/tz/1993-November/009236.html
- reshlo 2y ago
  > So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round Those two facts aren’t connected. At the time that those 28 minutes were skipped, Iceland was using the equivalent of UTC-01:00.
  - AdhemarVandamme 2y ago
    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.
    - reshlo 2y ago
      That’s a good point, I didn’t think about that.
- amiga386 2y ago
  I should point out that UTC didn't begin until 1960... The 28 minutes jump is likely Iceland coming into alignment with GMT, for much the same reasons as Ireland did; to improve trade and commerce in a world now using telegraphs, telephones and trains. We're ok becoming disconnected from mean solar time in order to connect more with each other. Samoa skipped a day in 2011, jumping from UTC−11:00 to UTC+13:00, so that it could align with Australia and New Zealand, its biggest trading partners -- so Australia's Friday is also Samoa's Friday. We'll always have discontinuities in civil timekeeping, as it's there to serve the whims of humans, not the other way around.

Cthulhu_ 2y ago

I wonder what happens when a timezone ceases to exist, e.g. what if Paris is renamed to New New York after the British take revenge and take over France.

jitl 2y ago
A timezone changing or being eliminated doesn’t erase the history of that timezone. So you can still use the last definition of such a timezone if the date is still in the future, or use the appropriate definition of the timezone at the time of a date marked in the past.
- williamdclt 2y ago
  > 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.
  - jitl 2y 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 https://github.com/eggert/tz/blob/main/backward for all the deprecated zones.
tomhallett 2y ago
Your example of “New X” is spot on, because there was a timezone with that name, “US/Pacific-New”, which was different than “US/Pacific”. Bit of history: it was added to some timezone libraries because there was a bill in congress to add it, but it never passed. I had to fix a bug because users were getting set with that timezone and then other systems/libraries were barfing on it… https://github.com/moment/moment-timezone/issues/498 https://github.com/moment/moment-timezone/issues/498
mason55 2y ago
Here are a couple starting points https://medium.com/servicios-a0/on-solving-the-tzdb-changes-problem-7b9fa8f96b86 https://medium.com/servicios-a0/on-solving-the-tzdb-changes-... https://github.com/tc39/proposal-canonical-tz 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
- justingrantjg 2y ago
  > https://github.com/tc39/proposal-canonical-tz 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 https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database
Macha 2y ago
Then Europe/Paris will become an alias for Europe/NewNewYork
- williamdclt 2y ago
  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
  - JW_00000 2y ago
    If I understand [1] correctly, two new zones (or one new one and the old one) would be created in that case. E.g. if Strasbourg would be occupied by Germany in 2027, a new Europe/Strasbourg could be created which has the same rules as Europe/Paris until 2026, and the rules of Europe/Berlin as of 2027. [1] https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database -- By the way, I looked up the time zone in Crimea. > On 29 March 2014, after annexation by Russia, Crimea switched from Eastern European Time (UTC+02:00) to Moscow Time (UTC+04:00 then, subsequently changed to UTC+03:00). [2] Crimea has its own zone in the IANA database, Europe/Simferopol, which was updated in 2014 (and already existed before, as it already used Moscow time from 1994 to 1997). [3] [2] https://en.wikipedia.org/wiki/Time_in_Ukraine https://en.wikipedia.org/wiki/Time_in_Ukraine [3] https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/DSQMDSIJMAERCKJNB2LQF2OZHO5EA72H/#VJJQUQZCUDSMM2RIXBZB75IROWQT2UOF https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/DS...; https://github.com/eggert/tz/commit/bb203f1bb0b6cd4bb2b08f2560a3e564a5614c59 https://github.com/eggert/tz/commit/bb203f1bb0b6cd4bb2b08f25...; https://github.com/eggert/tz/blob/bb203f1bb0b6cd4bb2b08f2560a3e564a5614c59/europe#L2942 https://github.com/eggert/tz/blob/bb203f1bb0b6cd4bb2b08f2560...
WorldMaker 2y ago
https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03-2023-en https://www.icann.org/en/blogs/details/how-time-zones-are-co... Hopefully the British would be kind enough to email the TZ DB group at the IANA (tz@iana.org) a couple years in advance of the legislation to change the name so that the group can get started on collecting the DST rules for Europe/NewNewYork. Some people and devices will probably stick to Europe/Paris out of habit and/or resistance to the change, so the TZ DB would probably be unlikely to remove it, but they may point references from it to Europe/NewNewYork as the new "canonical" name. Plenty of the DB entries are just pointers to other entries already today, for one instance it was decided that America/City and Europe/City maybe is too conflicted a namespace and we see increasingly more "the canonical name is America/State/City" or "the canonical name is Europe/Country/City".
- mikepurvis 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - mjevans 2y ago
    How about something like: Sol3/CA/Toronto I'd also like all 50 state capitols (and possibly also their largest city) to exist as E.G. Sol3/US/WA-Olympia and Sol3/US/WA-Seattle (respectively to the above; I don't know Canadian provinces that well) Sol3 is a prefix for the 3rd planet (starting ordinal 1, but anything in the orbit of Sol can be Sol0) in our solar system. It's also nicely short so easy to type out in command lines. Every state _should_ have it's own TZ file, even if it's just an alias. That's a good forward compatible way of allowing the same config to work if future legislative efforts produce or remove timezones. It would also allow E.G. Arizona's non DST timezone to remain correctly configured in some future where the US finally ends the nightmare of DST forever.

phiresky 2y ago

That but also and for me more importantly it does not tell you how to add time - If you add one month of hours to a date in October, it depends on the timezone whether you will end up one hour of local time earlier or not (due to DST), because then +02:00 might be +01:00

roywashere 2y ago
While this is true, most often if you want to do "now plus a month" you'll mean "at the same time on the local clock", and disregarding timezone changes, while most often if you want to do "now plus four hours" you'd actually mean four real hours, and you want to calculate in the DST changes to make sure you have four actual hours in your duration
- burntsushi 2y ago
  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.
  - btown 2y ago
    https://datatracker.ietf.org/doc/rfc9557/ https://datatracker.ietf.org/doc/rfc9557/ for folks' reference about the new [] suffix syntax. It's a really well thought out RFC: the offset, the civil time zone name, and a flag for whether that civil time zone is critical information can all be stored, and an inconsistency marked critical MUST be acted upon by the application explicitly, either by rejecting or requesting user interaction. This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I honor the absolute point in time, or do I honor the notion of 5pm?" Unfortunately, there's going to be a lot of chaos if this happens. Systems like Postgres only store the absolute point in time, normalized to UTC, despite what the name "timestamp with time zone" might imply; an application team or DBA making a decision about this might need to look at other domain-specific metadata e.g. the physical location of the associated asset to determine whether to add or remove an hour. I shudder to think about what this might imply for e.g. HIPAA protected medical systems; the impact of the ensuing bugs might be measured in lives.

tharkun__ 2y ago

Even countries that are on UTC don't save you from this. I had no idea until very recently but there is a time that simply never existed in Iceland! Wednesday January 2st 1908 00:00 clocks were turned forward 28 minutes to 00:28. So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round and one might think they are the best and easiest country to handle timezone wise. https://mm.icann.org/pipermail/tz/1993-November/009236.html https://mm.icann.org/pipermail/tz/1993-November/009236.html

reshlo 2y ago
> So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round Those two facts aren’t connected. At the time that those 28 minutes were skipped, Iceland was using the equivalent of UTC-01:00.
- AdhemarVandamme 2y ago
  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.
  - reshlo 2y ago
    That’s a good point, I didn’t think about that.
amiga386 2y ago
I should point out that UTC didn't begin until 1960... The 28 minutes jump is likely Iceland coming into alignment with GMT, for much the same reasons as Ireland did; to improve trade and commerce in a world now using telegraphs, telephones and trains. We're ok becoming disconnected from mean solar time in order to connect more with each other. Samoa skipped a day in 2011, jumping from UTC−11:00 to UTC+13:00, so that it could align with Australia and New Zealand, its biggest trading partners -- so Australia's Friday is also Samoa's Friday. We'll always have discontinuities in civil timekeeping, as it's there to serve the whims of humans, not the other way around.