Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Temporal is coming

developer.mozilla.org

Post reply on HN
Print view View original

201–210 of 416 posts

Re: JavaScript Temporal is coming

#201

Post by crowcroft »

TheAceOfHearts wrote: post #2

They should add an event to detect when someone changes timezones. That could be another entry in the "falsehoods that programmers believe about time": programmers believe that your timezone is fixed during usage. But in reality there are millions of people moving between timezones every day.

Since this requires state to track should be up to the developer to define how they want to track and respond to changes in timezone? I'm not sure I would want Temporal to have an opinion on how to handle that?

Re: JavaScript Temporal is coming

#202

Post by ARandumGuy »

My work does a lot of stuff with time and scheduling, and let me tell you having timezone-unaware date/time objects distinct from specific points in time will be so damn useful. The old Date class made it really easy to accidentally screw that up. Third party libraries help, but something as important and fundamental as time really should have a good built-in implementation.

Re: JavaScript Temporal is coming

#203

Post by gmac »

burntsushi wrote: post #168
btown wrote: post #159

Earlier quoted context omitted.

https://datatracker.ietf.org/doc/rfc9557/ for folks' reference about the new [] suffix syntax. It's a really well thought out RFC: the offset, the civil time zone name, and a flag for whether that civil time zone is critical information can all be stored, and an inconsistency marked critical MUST be acted upon by the application explicitly, either by rejecting or requesting user interaction. This may seem redundant,…

Yeah the PostgreSQL situation is just utterly appalling. The fact that there is a type called "timestamp with time zone," that specifically calls out the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown. > This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I ho…

I agree, but I believe Postgres is just following the SQL standard here?

What's even crazier is that writing plain TIMESTAMP gets you TIMESTAMP WITHOUT TIME ZONE, as is also mandated by the standard (the Postgres docs call this one out specifically). And that behaviour can be summarized as: not only don't store the timezone, but also ignore the timezone you get given.

For example, I'm on GMT/UTC right now, and I see this:

    select '2025-01-30T12:00:00-0800'::timestamp with time zone; -- 2025-01-30 20:00:00+00
    select '2025-01-30T12:00:00-0800'::timestamp; -- 2025-01-30 12:00:00

Re: JavaScript Temporal is coming

#204

Post by burntsushi »

Macha wrote: post #192
burntsushi wrote: post #137

Earlier quoted context omitted.

Can you check out the Brazil example in the docs I linked? That really should clear everything up. It explains how a datetime in the future gets serialized, but after a DST change, that serialized datetime becomes invalid. The way this works is by looking at offsets. Think of a time zone as a function mapping between civil time and physical time. Or, another way to think about it is a mapping from a civil time to an…

So in my use cases, there's three types of dates that matter: 1. Past dates. These can be stored UTC, and just rendered in the appropriate timezone as a matter of formatting. 2. Future non-human dates: e.g. the next execution time of a job that runs every hour. These can just be UTC 3. Future human dates: I care about the human selected timezone so that events happen on the wall clock time the user expects. The UTC t…

For that specific use case, sure! But Temporal isn't for Macha's 3 use cases. Not all future datetimes are only concerned with civil time. Some are concerned with the precise instant in time. So how do you choose which one? There is no one universal right answer, so IMO, the right default is to reject.

But if you know your use cases and know you always want to adhere to civil time even if it means a change in the precise instant, then Temporal supports that too:

    >> zdt = Temporal.ZonedDateTime.from("2025-06-20T17:00+08[US/Eastern]")
    Uncaught RangeError: Offset +08:00 is invalid for 2025-06-20T17:00:00 in US/Eastern
        InterpretISODateTimeOffset ecmascript.mjs:1467
        ToTemporalZonedDateTime ecmascript.mjs:1531
        from zoneddatetime.mjs:478
         debugger eval code:1
    >> zdt = Temporal.ZonedDateTime.from("2025-06-20T17:00+08[US/Eastern]", {offset: 'ignore'})
    >> zdt.toString()
    "2025-06-20T17:00:00-04:00[US/Eastern]"
> So in cases 1 and 2, having a non-UTC date is not required

If the only operation you need is formatting, then I agree, you can apply the time zone to the instant right before it's displayed. But there are many other operations (such as arithmetic or computing durations between datetimes) you might want to do that do required a time zone. You might still be able to get away with only storing a UTC date, but it really depends on what you're doing.

Re: JavaScript Temporal is coming

#206

Post by tshaddox »

taeric wrote: post #154
troupo wrote: post #67

Earlier quoted context omitted.

You've just introduced timezones

It always cracks me up when people think they are proposing a simpler system by ignoring complexity. Is akin to people saying, "why don't we just change the start/end time of schools/businesses instead of changing the clock back?" As if getting companies to agree to when to make a change, and updating all of their documents/signage/etc. would somehow be easier than allowing them to continue to say "open at 8." For th…

My bank opens at 9am. My pharmacy opens at 8am. The corner cafe opens at 7:30 but is completely closed on Wednesdays. This "complexity," if you want to call it that, requires very little cognitive load, and certainly doesn't require any standardized features to be added to every operating system and programming language standard library.

Re: JavaScript Temporal is coming

#207

Post by burntsushi »

gmac wrote: post #203
burntsushi wrote: post #168

Earlier quoted context omitted.

Yeah the PostgreSQL situation is just utterly appalling. The fact that there is a type called "timestamp with time zone," that specifically calls out the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown. > This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I ho…

I agree, but I believe Postgres is just following the SQL standard here? What's even crazier is that writing plain TIMESTAMP gets you TIMESTAMP WITHOUT TIME ZONE, as is also mandated by the standard (the Postgres docs call this one out specifically). And that behaviour can be summarized as: not only don't store the timezone, but also ignore the timezone you get given . For example, I'm on GMT/UTC right now, and I see…

There are many valid and justifiable reasons to do crazy things. But it's still crazy. :-)

I don't think that completely absolves PostgreSQL though. It seems like they could add things to improve the situation and de-emphasize the use of TIMESTAMP and TIMESTAMP WITH TIME ZONE. But I am not a database or PostgreSQL expert, and there are assuredly trade-offs with doing this.

But yes, absolutely, the fact that TIMESTAMP is not just a timestamp without a time zone, but is actually a civil time is also equal parts crazytown. Like, a timestamp is 100% an instant in time. It is physical time. A number of seconds since an epoch. But PostreSQL (or the SQL standard) interprets it as a civil time? It's ludicrous and has assuredly confused countless humans. Especially those among us who don't know enough to question that PostgreSQL (or the SQL standard) might have gotten it wrong in the first place.

Re: JavaScript Temporal is coming

#210

Post by Macha »

SkyBelow wrote: post #128
BostonFern wrote: post #85

It’s almost a shame, considering all the effort that went into Moment and Luxon, which will largely be superseded. Luxon especially is a joy to work with.

I spent a day fighting with date-fns trying to get some date calculations working and was to the point I was questioning if my entire approach was flawed because there was no reason I should be spending that much time figuring our some simple date calculations. Eventually I decided to try swapping to Luxon. 30 minutes later and it was all working. I'm still guessing I misunderstood something fundamental about date-fn…

For the longest time date-fns approach to timezones was "Do you really need timezones? Aren't UTC offsets enough?" which was pretty fatal for a date time library, no matter how simple and light it makes your bundle.

It looks like they did finally launch TZ support in September last year, and I haven't investigated it (and probably never will, given Temporal is coming a Temporal polyfill seems a better option)

Post reply on HN