Hacker News Reader

Comment by ggregoire | Hacker News Reader

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

View on HN

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

[2] https://en.wikipedia.org/wiki/Tz_database

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.

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.

Please don't forget about us node users (and deno and bun I guess, too).

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

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

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.

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.

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

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.

Really, can you give a more specific example? I have never had a node upgrade break my code, and would be fairly surprised if I were to run into that situation! I also don't quite understand your other points - runtime environments are isolated, that's the point of the node_modules folder, and it's one of the things that Node/NPM does particularly well at. Were you installing your packages globally?

You must be lucky. Anything the relies on their floating ABI breaks on every update (C dependencies are very common for certain tasks)

Yeah it’s pretty much this. Something simple like scss/sass breaks a little too often but that’s the easy case. When it’s a Postgres driver it gets even more interesting.

See my other comment but also npm is installed globally and global packages are available so there is no isolation. Compare to Python where a virtual env is complete with a separate copy of the Python interpreter, associated tools (pip, etc.), and only local packages are available. And best of all, you can call binaries inside the virtual env from outside it as normal executables and it just works. No need to mess with $PATH or set any other env variables, just call ./venv/bin/foobar and foobar will run in the context of that venv. Recreating this on a different machine is amazingly simple if you can use one of the already available Python binaries on that system, and trivial if not (compiling Python takes a few minutes and there are lots of tools that will make that process even simpler than the two commands you need to do it). People talk about Docker being the universal environment to run things but Python development doesn’t even need that 99% of the time. And the standard library is chock full of sane, performant modules that allow you to do everything you need, from asyncio to parsing arcane binary formats. My installed packages typically number in dozens, not thousands like JS, because the standard library provides so much already.

Using only the bundled APIs of node and python, I feel like python breaks more often, like for example the useless rename from `collections` to `collections.abc`.

Oh man 12 -> 20 must have hurt. In my experience, Node really stepped up their game in most any regard after the iojs split, and these days I've had almost zero problems jumping from one major LTS release to the next.

Can't guarantee no issues, but my gut feel is you'll have a much better experience with 20 -> 24 for example.

deno added this about a year ago https://docs.deno.com/api/web/~/Temporal https://deno.com/blog/v1.40#temporal-api

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.

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

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.

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.

Reply on news.ycombinator.com