[wesselbindt]

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.

[anowell]

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

[lightwords]

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

[rafram]

  $ du -sh '/Applications/Google Chrome.app'
   1.3G    /Applications/Google Chrome.app

[lightwords]

There are numerous reports on this being an issue e.g. https://issues.chromium.org/issues/40624456

[anowell]

Thanks for the heads up. Will think on this and will probably just document the polyfill.

[jacquesm]

That's complete crazy.

[TimTheTinker]

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?

[698969]

That looks neat although your package is missing a link to the source repository.

[anowell]

Good catch. Will get that added today.

github.com/howie-code/temporal-fun

[throwaway_12629]

Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.

[dskloet]

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.

[usefulcat]

    // call foo() one day from now:
    sleep(86400); foo();

[hdjrudni]

Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.

[koakuma-chan]

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.

[danbruc]

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.

[koakuma-chan]

Why do you want something to happen everyday at 12 o'clock specifically? If this is truly what you want, sure.

[danbruc]

Lunch break reminder popup?

[loloquwowndueo]

Only if you live in one of the brain dead countries that observe the dst anachronism.

[eureka7]

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.

[mklepaczewski]

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.

[koakuma-chan]

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.

[mklepaczewski]

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.

[manarth]

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.

[troad]

> 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?

[jacquesm]

Cue a longish article titled 'Falsehoods Programmers Believe About Time'

[SOLAR_FIELDS]

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?

[zelphirkalt]

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.

[SOLAR_FIELDS]

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.

[zelphirkalt]

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.

[SOLAR_FIELDS]

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.