News for hackers. Stuff that matters.

A comment on Temporal: The 9-Year Journey to Fix Time in JavaScript.

Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by wesselbindt on Wednesday March 11, 2026 @06:56PM (#47343541)
I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug any day of the week.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by throwaway_12629 on Wednesday March 11, 2026 @08:13PM (#47344452)
Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by usefulcat on Wednesday March 11, 2026 @08:39PM (#47344694) 

    // call foo() one day from now:
    sleep(86400); foo();
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by hdjrudni on Thursday March 12, 2026 @12:34AM (#47346481)
Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by koakuma-chan on Thursday March 12, 2026 @01:53AM (#47347009)
What you want there is to stop saying "day" and instead say "24 hours." This way the code is correct and you don't need to deal with time weirdness.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by danbruc on Thursday March 12, 2026 @05:10AM (#47348218)
No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by loloquwowndueo on Thursday March 12, 2026 @06:37AM (#47348808)
Only if you live in one of the brain dead countries that observe the dst anachronism.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by eureka7 on Thursday March 12, 2026 @09:32AM (#47350308)
ok, but they still observe it and you still have to deal with it in your code.

our personal convictions don't change that fact.

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by koakuma-chan on Thursday March 12, 2026 @10:24AM (#47350953)
Why do you want something to happen everyday at 12 o'clock specifically? If this is truly what you want, sure.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by danbruc on Thursday March 12, 2026 @05:14PM (#47357221)
Lunch break reminder popup?
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by mklepaczewski on Thursday March 12, 2026 @06:08AM (#47348572)
You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are: - 23 hours - 25 hours - 24 hours 1 second - 23 hours 59 minutes 59 seconds

You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close.

And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure of time (second smearing).

To make things worse, those are "simple" edge cases.

Time is hard. I'm not sure if I can make any statement about time that is true.

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by koakuma-chan on Thursday March 12, 2026 @10:35AM (#47351125)
I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by mklepaczewski on Thursday March 12, 2026 @12:11PM (#47353002)
It depends on the context and the system you’re working with. In some systems, an hour may last 3599, 3600 or 3601 seconds (due to the leap second), a minute may be 59,60 or 61 seconds. Even a second is not always a „true” second.

There’s no single time unit that works for all situations.

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by dskloet on Thursday March 12, 2026 @01:06AM (#47346718)
That's a great example of the kind of wrong assumption that makes dealing with dates and times so challenging.

Some countries start on a Friday or Saturday and until 2022 Iran could start any day of the week although never at 3AM.

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by manarth on Thursday March 12, 2026 @09:00AM (#47349968)
Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.

Ramadan is observed from one visual sighting of a crescent moon to the next.

Cloud conditions may prevent sighting and thereby alter the official start of Ramadan for an individual location, and from time-to-time, the start of a country's change in timezone.

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by jacquesm on Thursday March 12, 2026 @09:02AM (#47349999)
Cue a longish article titled 'Falsehoods Programmers Believe About Time'
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by troad on Thursday March 12, 2026 @08:02PM (#47359015)
> Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.

Only Morocco does this, I believe, and it's not even clear that that's actually official time at this point. In 2018, Morocco abolished DST, but it seems unclear what that means in practice.

I'd love it if someone from Morocco could weigh in on what the actual situation is on the ground. Do people still change their clocks for Ramadan? Would they be annoyed if a website kept Moroccan users on standard time during Ramadan?

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by SOLAR_FIELDS on Wednesday March 11, 2026 @09:18PM (#47345022)
In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by zelphirkalt on Thursday March 12, 2026 @12:08PM (#47352939)
If you want to understand what is going on at all, then yes, good abstraction layers do matter, and a lot at that. Hashtag cognitive debt.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by SOLAR_FIELDS on Friday March 13, 2026 @07:48PM (#47371584)
Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have an LLM parse it and explain it to you than doing it yourself.

And the LLM doesn’t care. You could hand it a pile of the best code ever and a pile of brainfuck and probably the difference between comprehending one over the other is in the seconds if not milliseconds of compute time.

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by zelphirkalt on Saturday March 14, 2026 @06:36AM (#47375254)
This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issue I saw with a widget or making a custom widget (Python, tkinter). I don't think it will fare much better when analyzing existing code, because ultimately it does not understand things.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by SOLAR_FIELDS on Saturday March 14, 2026 @06:54PM (#47382154)
Given the stochastic nature, if I am forced to have to dig into the code because the LLM couldn't figure it out perhaps one out of every 10 times, it's still a huge bonus. Probably it depends on what you are working on. Esoteric COBOL? Erlang? Yeah good luck, you're probably hand steering the thing while the frontier model providers figure out how to train it better. Vanilla-ish Python/Golang/Typescript/Java? I pretty much never have to do that nowadays for things the model is familiar with. If i do have to dig into the code, I've never regretted doing it this way, because 90% of my use cases worked just fine, and in those 90% of use cases I was able to produce working code at 20x the rate of hand writing it if not more. Feels like a huge win to me.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by anowell on Thursday March 12, 2026 @12:51AM (#47346596)
Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases.

npmjs.com/package/temporal-fun

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by 698969 on Thursday March 12, 2026 @06:09AM (#47348578)
That looks neat although your package is missing a link to the source repository.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by anowell on Thursday March 12, 2026 @07:58AM (#47349398)
Good catch. Will get that added today.

github.com/howie-code/temporal-fun

[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by lightwords on Thursday March 12, 2026 @06:30AM (#47348743)
Word of warning Temporal relies on the Intl API for formatting, and support in Chrome is very limited due to their binary size constraints. As a result, you'll need to polyfill unsupported languages using format.js
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by rafram on Thursday March 12, 2026 @06:43AM (#47348872) 

  $ du -sh '/Applications/Google Chrome.app'
   1.3G    /Applications/Google Chrome.app
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by lightwords on Thursday March 12, 2026 @06:56AM (#47348978)
There are numerous reports on this being an issue e.g. https://issues.chromium.org/issues/40624456
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by anowell on Thursday March 12, 2026 @08:05AM (#47349449)
Thanks for the heads up. Will think on this and will probably just document the polyfill.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by jacquesm on Thursday March 12, 2026 @09:01AM (#47349980)
That's complete crazy.
[ Parent | on HN ]
Re:Temporal: The 9-Year Journey to Fix Time in JavaScript by TimTheTinker on Thursday March 12, 2026 @10:52AM (#47351439)
Format.js polyfills a lot of stuff that's already supported in modern browsers, and seems to prefer its own polyfills to the native APIs.

Is there any way to force it to only use (and bundle) the polyfills that are needed assuming 2025+ era browsers?

[ Parent | on HN ]