4 ms·

It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets

It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets. That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. All of this is kept track of in the IANA Time Zone database, and labels like `Europe/Paris` are from keys into that database, not arbitrary. https://www.iana.org/time-zones https://www.iana.org/time-zones Sometimes when jurisdictions do weird stuff like changing their rules for (say) when Daylight Savings starts with no notice (effective tomorrow!), the libraries can take a bit of time to catch up and be correct again (and have the new version be distributed to all users). But keeping track of (say) that America/New York on March 25 2024 is UTC-4 but March 2025 1990 is UTC-5 hours (they changed when Daylight Savings started in between those years) is absolutely something current (eg OS) time libraries do. As well as keeping track of the gregorian correction in (depending on country) October 1582 (skipping over 10 days in the calendar!), when calculating historical intervals. They really do this, already! That's why you say "Europe/Paris" or "America/New York" instead of "UTC-5", to let the library figure out the rules for offsets at that location on the time specified. I assume Temporal will do the same. JS environments are usually running on OS's that will already provide this service, the browser or other execution environment won't have to implement it from scratch. Although I think moment.js did it from scratch, and distributes a timezone database with moment.js packages.

burntsushi 2y ago
> As well as keeping track of the gregorian correction in (depending on country) October 1582 (skipping over 10 days in the calendar!), when calculating historical intervals. They really do this, already! Which libraries do this? Libraries usually implement proleptic calendars, including Temporal[1], which specifically do not account for shifts like this. And indeed, the Temporal docs even call out this specific example. (I agree with the rest of your comment!) [1]: https://tc39.es/proposal-temporal/docs/calendars.html#handling-unusual-dates-leap-days-leap-months-and-skipped-or-repeated-periods https://tc39.es/proposal-temporal/docs/calendars.html#handli...
- jrochkind1 2y ago
  Ah, I guess not as many as I thought! Ruby DateTime does it, I hadn't realized it was unusual, if it is! Here it is particularly called out in documentation with example taking account that April 23rd 1616 in England was not the same day as April 23rd 1616 in Italy, and DateTime knows that! https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime.html#class-DateTime-label-When+should+you+use+DateTime+and+when+should+you+use+Time-3F https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime.... (That class however is using weird "Date::ENGLAND" constants for locale instead of ISO timezone locales, which is a legacy mistake!) (I work in archiving cultural history, so probably deal with pre-19th century dates a lot more than the average coder) update: I was curious what would happen if I gave DateTime a non-existent date... DateTime.iso8601('1752-09-05', Date::ENGLAND) => invalid date (Date::Error) it knows! (England skipped some days in September 1752 as part of Gregorian adjustment)
  - burntsushi 2y ago
    Ah yeah, those look like opt-in calendars to me I think. Definitely other datetime libraries do that. They just also require opt-in AFAIK.
    - jrochkind1 2y ago
      Ruby date/time handling is confusing, with too many overlapping classes, developed at different times with odd interfaces and/or semantic edge cases (not unusual on other platforms either), but I believe the things people use as default/recommended standard these days on ruby actually do support gregorian/julian changeover! But I guess ruby is unusual there! Or I'm wrong. But good to know most have it as opt-in, anyway!
      - burntsushi 2y ago
        I would need to see the APIs and examples to be able to evaluate it honestly. (FWIW, I'm the author of a datetime library in Rust called Jiff.)
mason55 2y ago
> That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city. You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose. If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited. For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time. Location-based tz's are the best we can do right now but even still they have intractable problems when things change.
- jrochkind1 2y ago
  Right, I mean that if in 2030 for some odd reason half of Punta Arenas does DST and half does not, then 'America/Punta_Arenas' would not work as a timezone designator anymore! Obviously unlikely, I probably should not have mentioned it.
- justingrantjg 2y ago
  Yep. That said, for end users it's a fairly good story because consumer OSs have gotten very good at automatically adjusting clients' time zone based on geo-location. Just like when you fly to another country and the first thing that happens when you connect your laptop to the internet is you're offered to change your time zone to the local time zone. I assume that the same thing happens when you're in a place whose IANA time zone changes like your America/Punta_Arenas case or many others like it.

burntsushi 2y ago

> As well as keeping track of the gregorian correction in (depending on country) October 1582 (skipping over 10 days in the calendar!), when calculating historical intervals. They really do this, already! Which libraries do this? Libraries usually implement proleptic calendars, including Temporal[1], which specifically do not account for shifts like this. And indeed, the Temporal docs even call out this specific example. (I agree with the rest of your comment!) [1]: https://tc39.es/proposal-temporal/docs/calendars.html#handling-unusual-dates-leap-days-leap-months-and-skipped-or-repeated-periods https://tc39.es/proposal-temporal/docs/calendars.html#handli...

jrochkind1 2y ago
Ah, I guess not as many as I thought! Ruby DateTime does it, I hadn't realized it was unusual, if it is! Here it is particularly called out in documentation with example taking account that April 23rd 1616 in England was not the same day as April 23rd 1616 in Italy, and DateTime knows that! https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime.html#class-DateTime-label-When+should+you+use+DateTime+and+when+should+you+use+Time-3F https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime.... (That class however is using weird "Date::ENGLAND" constants for locale instead of ISO timezone locales, which is a legacy mistake!) (I work in archiving cultural history, so probably deal with pre-19th century dates a lot more than the average coder) update: I was curious what would happen if I gave DateTime a non-existent date... DateTime.iso8601('1752-09-05', Date::ENGLAND) => invalid date (Date::Error) it knows! (England skipped some days in September 1752 as part of Gregorian adjustment)
- burntsushi 2y ago
  Ah yeah, those look like opt-in calendars to me I think. Definitely other datetime libraries do that. They just also require opt-in AFAIK.
  - jrochkind1 2y ago
    Ruby date/time handling is confusing, with too many overlapping classes, developed at different times with odd interfaces and/or semantic edge cases (not unusual on other platforms either), but I believe the things people use as default/recommended standard these days on ruby actually do support gregorian/julian changeover! But I guess ruby is unusual there! Or I'm wrong. But good to know most have it as opt-in, anyway!
    - burntsushi 2y ago
      I would need to see the APIs and examples to be able to evaluate it honestly. (FWIW, I'm the author of a datetime library in Rust called Jiff.)

mason55 2y ago

> That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city. You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose. If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited. For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time. Location-based tz's are the best we can do right now but even still they have intractable problems when things change.

jrochkind1 2y ago
Right, I mean that if in 2030 for some odd reason half of Punta Arenas does DST and half does not, then 'America/Punta_Arenas' would not work as a timezone designator anymore! Obviously unlikely, I probably should not have mentioned it.
justingrantjg 2y ago
Yep. That said, for end users it's a fairly good story because consumer OSs have gotten very good at automatically adjusting clients' time zone based on geo-location. Just like when you fly to another country and the first thing that happens when you connect your laptop to the internet is you're offered to change your time zone to the local time zone. I assume that the same thing happens when you're in a place whose IANA time zone changes like your America/Punta_Arenas case or many others like it.