3 ms·

Anyone knows how the data about each timezone stays updated within Temporal? Does the TC39 update the data somewhere, then each browser copies that data interna

Anyone knows how the data about each timezone stays updated within Temporal? Does the TC39 update the data somewhere, then each browser copies that data internally and releases a new version of the browser? If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours? For example Mexico removed DST in 2022 [1]. When using third party libraries like pytz or moment-timezone, you just update the library on your side with the updated data for Mexico. Or bump the language if it's handled in the standard library. What about Temporal and my visitors' browser? [1] https://en.wikipedia.org/wiki/Time_in_Mexico https://en.wikipedia.org/wiki/Time_in_Mexico

infogulch 2y ago
Since it's built into the browser it's probably updated when the browser is updated. Browser vendors did a lot of work to update quickly, browsers are probably the most up-to-date software on your average person's computer.
- baq 2y ago
  Please don't forget about us node users (and deno and bun I guess, too).
  - rough-sea 2y ago
    deno added this about a year ago https://docs.deno.com/api/web/~/Temporal https://docs.deno.com/api/web/~/Temporal https://deno.com/blog/v1.40#temporal-api https://deno.com/blog/v1.40#temporal-api
  - infogulch 2y ago
    If you're running years old js runtimes in a bigcorp that doesn't feel like updating for the next decade, I'll pray for you. (Because there's nothing else to do.)
    - 91bananas 2y ago
      Smolcorp here, we just went from 12-20 across several large projects, it was gnarly. And now, 20 is already set to sunset soon. at some point it just feels like you should give up trying, but I'm hoping 20 to >20 isn't as bad as 12 -> 20
      - infogulch 2y ago
        Picking Javascript as the foundation of your project and being dismayed at how much work it takes to keep up is a restatement of the definition of insanity.
      - beart 2y ago
        I know it doesn't always work out, but it definitely helps to keep current, rather than performing a massive update every X years. Most of the time the changes are minimal, but they add up over several major revisions. Of course, every now and then something like eslint will completely break every project in existence by changing the configuration format, then you have to wait for all of the plugins to be updated (if ever), then hope all your linting rules are still valid... yeah I'm still bitter about that one.
        phatskat 2y ago
        I just moved an eslint config from a project started a little over a year ago to a fresh project and migrating the config took up way more time than I expected. The old config had options that didn’t make sense in the new config, or that weren’t covered in the migration docs, etc. I think it all works now but who knows if some odd rule got missed and that’s just that from now on
      - IgorPartola 2y ago
        I work with both node and Python. The difference in upgrade experiences is measured in several orders of magnitude. My most recent few projects jumped Python versions because features I wanted were introduced. I cannot remember a time I had to rewrite application code because of an upgraded Python version (well I do, it was the Python 2 to 3 migration a very long time ago). In the meantime new node versions constantly break backwards compatibility. Upgrading packages is a mess. Runtime environments are not properly isolated, third party packages sometimes explicitly do not work with specific versions of node, etc. For a community so focused on creating tooling, it has the worst tools of any ecosystem I have seen. I would rather work with C than with node.
burntsushi 2y ago
On Unix systems (including Linux distros, macOS and Android), there is a system copy of the IANA Time Zone Database. I actually don't know if browsers use that or if they ship their own copy. But Temporal definitely uses the IANA tzdb. > If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours? Yeah I think this is generally correct. But I don't think that's a departure from current norms? I think this is also just true in general. If the user doesn't update to their system to account for new time zone transition rules then that's just kinda how the cookie crumbles. The alternative is that every application ships their own tzdb. And to be clear, some do that and sometimes it is warranted. But in general this would be wasteful and likely lead overall to inconsistency between applications and likely a slower cadence of updates. (Because now every application has to be updated and shipped out again.)
- WorldMaker 2y ago
  Windows has its own complex in different ways system-wide Time Zone Database, but these days also has a full IANA Time Zone Database compatibility layer.
haburka 2y ago
Reading the proposal page “ Time Zones and Resolving Ambiguity”[1], it only mentions that it uses the IANA time zone database[2] not when it updates it. However I imagine the users computer has access to this database as well and probably handles it being updated. I’m not sure about this. It’s also entirely possible for the browser to download this database and maintain it too, separately from updates. I’m sure it depends on the implementation. [1] https://tc39.es/proposal-temporal/docs/timezone.html https://tc39.es/proposal-temporal/docs/timezone.html [2] https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database
- thayne 2y ago
  Yes, the user's operating system probably already has an IANA database somewhere, or the browser could bundle its own IANA database. And the browser probably already has some way to access that database anyway.
nekevss 2y ago
It's going to depend on the implementation and the system. The implementation will probably end up needing to define a time zone provider, which will ultimately be provided by host/system hooks provided to Temporal from the engine implementation.
sureIy 2y ago
Browsers already have to stay up to date with locales due to the Intl helpers so researching that would likely lead to the same answer.

infogulch 2y ago

Since it's built into the browser it's probably updated when the browser is updated. Browser vendors did a lot of work to update quickly, browsers are probably the most up-to-date software on your average person's computer.

baq 2y ago
Please don't forget about us node users (and deno and bun I guess, too).
- rough-sea 2y ago
  deno added this about a year ago https://docs.deno.com/api/web/~/Temporal https://docs.deno.com/api/web/~/Temporal https://deno.com/blog/v1.40#temporal-api https://deno.com/blog/v1.40#temporal-api
- infogulch 2y ago
  If you're running years old js runtimes in a bigcorp that doesn't feel like updating for the next decade, I'll pray for you. (Because there's nothing else to do.)
  - 91bananas 2y ago
    Smolcorp here, we just went from 12-20 across several large projects, it was gnarly. And now, 20 is already set to sunset soon. at some point it just feels like you should give up trying, but I'm hoping 20 to >20 isn't as bad as 12 -> 20
    - infogulch 2y ago
      Picking Javascript as the foundation of your project and being dismayed at how much work it takes to keep up is a restatement of the definition of insanity.
    - beart 2y ago
      I know it doesn't always work out, but it definitely helps to keep current, rather than performing a massive update every X years. Most of the time the changes are minimal, but they add up over several major revisions. Of course, every now and then something like eslint will completely break every project in existence by changing the configuration format, then you have to wait for all of the plugins to be updated (if ever), then hope all your linting rules are still valid... yeah I'm still bitter about that one.
      - phatskat 2y ago
        I just moved an eslint config from a project started a little over a year ago to a fresh project and migrating the config took up way more time than I expected. The old config had options that didn’t make sense in the new config, or that weren’t covered in the migration docs, etc. I think it all works now but who knows if some odd rule got missed and that’s just that from now on
    - IgorPartola 2y ago
      I work with both node and Python. The difference in upgrade experiences is measured in several orders of magnitude. My most recent few projects jumped Python versions because features I wanted were introduced. I cannot remember a time I had to rewrite application code because of an upgraded Python version (well I do, it was the Python 2 to 3 migration a very long time ago). In the meantime new node versions constantly break backwards compatibility. Upgrading packages is a mess. Runtime environments are not properly isolated, third party packages sometimes explicitly do not work with specific versions of node, etc. For a community so focused on creating tooling, it has the worst tools of any ecosystem I have seen. I would rather work with C than with node.

burntsushi 2y ago

On Unix systems (including Linux distros, macOS and Android), there is a system copy of the IANA Time Zone Database. I actually don't know if browsers use that or if they ship their own copy. But Temporal definitely uses the IANA tzdb. > If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours? Yeah I think this is generally correct. But I don't think that's a departure from current norms? I think this is also just true in general. If the user doesn't update to their system to account for new time zone transition rules then that's just kinda how the cookie crumbles. The alternative is that every application ships their own tzdb. And to be clear, some do that and sometimes it is warranted. But in general this would be wasteful and likely lead overall to inconsistency between applications and likely a slower cadence of updates. (Because now every application has to be updated and shipped out again.)

WorldMaker 2y ago
Windows has its own complex in different ways system-wide Time Zone Database, but these days also has a full IANA Time Zone Database compatibility layer.

haburka 2y ago

Reading the proposal page “ Time Zones and Resolving Ambiguity”[1], it only mentions that it uses the IANA time zone database[2] not when it updates it. However I imagine the users computer has access to this database as well and probably handles it being updated. I’m not sure about this. It’s also entirely possible for the browser to download this database and maintain it too, separately from updates. I’m sure it depends on the implementation. [1] https://tc39.es/proposal-temporal/docs/timezone.html https://tc39.es/proposal-temporal/docs/timezone.html [2] https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database

thayne 2y ago
Yes, the user's operating system probably already has an IANA database somewhere, or the browser could bundle its own IANA database. And the browser probably already has some way to access that database anyway.

nekevss 2y ago

It's going to depend on the implementation and the system. The implementation will probably end up needing to define a time zone provider, which will ultimately be provided by host/system hooks provided to Temporal from the engine implementation.

sureIy 2y ago

Browsers already have to stay up to date with locales due to the Intl helpers so researching that would likely lead to the same answer.