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

11–20 of 20 posts

Re: JavaScript Temporal Is Coming

#11

Post by bakkoting »

mattdw wrote: post #8
paulryanrogers wrote: post #6

> Time-zone-unaware date/time ("Plain") Why?! The thing I hate most about most SQL DateTime/Timestamps are their choice to default to TZ ambiguity. Too often it means everything must actually be UTC nearly all the time, or you get messy data that could be any zone. I.e. It's a lossy data type. TZ unaware should not be an option. Or if there's truly a case for it then it should at least be some non default, opt in, wi…

Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England. I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a l…

> That's a thing that UTC or timezone-aware Datetimes can't help with.

Modern datetime systems (including Temporal) use identifiers rather than offsets, which are almost as good as a location as long as governments don't redraw the boundaries. And Auckland is in fact the canonical city for the main New Zealand timezone, so specifying your timezone as "Pacific/Auckland" will get you pretty much the thing you want. In Temporal, this would be e.g.

  Temporal.PlainDateTime.from({ year: 2025, month: 1, day: 1, hour: 9 })
    .toZonedDateTime('Pacific/Auckland')

Re: JavaScript Temporal Is Coming

#12

Post by paulryanrogers »

bakkoting wrote: post #9
paulryanrogers wrote: post #6

> Time-zone-unaware date/time ("Plain") Why?! The thing I hate most about most SQL DateTime/Timestamps are their choice to default to TZ ambiguity. Too often it means everything must actually be UTC nearly all the time, or you get messy data that could be any zone. I.e. It's a lossy data type. TZ unaware should not be an option. Or if there's truly a case for it then it should at least be some non default, opt in, wi…

Lots of things are logically timezone-unaware. E.g., I have an alarm that goes off at 6AM every day; it should do so whatever timezone I'm in. Or, some holiday happens on the 14th of the month, not for a specific 24-hour period in a specific timezone. These aren't "TZ ambiguous". These are "this thing does not logically have a specific associated timezone". For things which do logically have a specific associated tim…

Are there other examples besides alarms or task reminders?

Re: JavaScript Temporal Is Coming

#13

Post by bdangubic »

paulryanrogers wrote: post #12
bakkoting wrote: post #9

Earlier quoted context omitted.

Lots of things are logically timezone-unaware. E.g., I have an alarm that goes off at 6AM every day; it should do so whatever timezone I'm in. Or, some holiday happens on the 14th of the month, not for a specific 24-hour period in a specific timezone. These aren't "TZ ambiguous". These are "this thing does not logically have a specific associated timezone". For things which do logically have a specific associated tim…

Are there other examples besides alarms or task reminders?

everything you do repeatedly / as part of a routine. wake up, exercise, read/study, take medicine/insulin…

Re: JavaScript Temporal Is Coming

#14

Post by mattdw »

bakkoting wrote: post #11
mattdw wrote: post #8

Earlier quoted context omitted.

Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England. I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a l…

> That's a thing that UTC or timezone-aware Datetimes can't help with. Modern datetime systems (including Temporal) use identifiers rather than offsets, which are almost as good as a location as long as governments don't redraw the boundaries. And Auckland is in fact the canonical city for the main New Zealand timezone, so specifying your timezone as "Pacific/Auckland" will get you pretty much the thing you want. In…

For sure, but for future events to be correct I still have to store that as (plain datetime, pacific/auckland), not translated to utc at the point of creation/saving. If I store only a UTC datetime I have unrecoverable lost important information.

Re: JavaScript Temporal Is Coming

#15

Post by mattdw »

paulryanrogers wrote: post #10
mattdw wrote: post #8

Earlier quoted context omitted.

Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England. I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a l…

Even in your example those events do happen at a certain point in time. And if some attendees are virtual they may be several zones away. Ultimately people want to see their local TZ, whilst they want unambiguous data backing it. Alarms are something of a special case, and with TZ aware types one could still adapt at the application later. For a gift card system I once had relative expiration, enforced using the zone…

For events that have happened, absolutely. Events in the future are often slightly more ambiguous though!

I do agree that "with attached Timezone" or "as UTC" are absolutely the sensible defaults, I'm just suggesting that sometimes "plain" datetimes are semantically the correct choice.

Re: JavaScript Temporal Is Coming

#16

Post by Anon1096 »

bakkoting wrote: post #11
mattdw wrote: post #8

Earlier quoted context omitted.

Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England. I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a l…

> That's a thing that UTC or timezone-aware Datetimes can't help with. Modern datetime systems (including Temporal) use identifiers rather than offsets, which are almost as good as a location as long as governments don't redraw the boundaries. And Auckland is in fact the canonical city for the main New Zealand timezone, so specifying your timezone as "Pacific/Auckland" will get you pretty much the thing you want. In…

The alarm that I have set for 8AM every day shouldn't change to 3AM just because I moved time zones.

Re: JavaScript Temporal Is Coming

#18

Post by burntsushi »

mattdw wrote: post #14
bakkoting wrote: post #11

Earlier quoted context omitted.

> That's a thing that UTC or timezone-aware Datetimes can't help with. Modern datetime systems (including Temporal) use identifiers rather than offsets, which are almost as good as a location as long as governments don't redraw the boundaries. And Auckland is in fact the canonical city for the main New Zealand timezone, so specifying your timezone as "Pacific/Auckland" will get you pretty much the thing you want. In…

For sure, but for future events to be correct I still have to store that as (plain datetime, pacific/auckland), not translated to utc at the point of creation/saving. If I store only a UTC datetime I have unrecoverable lost important information.

That's exactly why Temporal uses RFC 9557 for its `ZonedDateTime` serialization format:

    >> zdt = Temporal.Now.zonedDateTimeISO()
    >> zdt.toJSON()
    "2025-01-24T19:57:01.089557834-05:00[America/New_York]"
    >> zdt.toString()
    "2025-01-24T19:57:01.089557834-05:00[America/New_York]"
Temporal will even check that the offset is still correct for the time zone when you deserialize.

Re: JavaScript Temporal Is Coming

#19

Post by burntsushi »

paulryanrogers wrote: post #6

> Time-zone-unaware date/time ("Plain") Why?! The thing I hate most about most SQL DateTime/Timestamps are their choice to default to TZ ambiguity. Too often it means everything must actually be UTC nearly all the time, or you get messy data that could be any zone. I.e. It's a lossy data type. TZ unaware should not be an option. Or if there's truly a case for it then it should at least be some non default, opt in, wi…

Temporal's main data type is ZonedDateTime.

PlainDateTime is there because it is necessary sometimes. The Temporal docs even outline some cases where you might want to use it: https://tc39.es/proposal-temporal/docs/plaindatetime.html

Temporal also makes it pretty hard to misuse its types. For example:

    >> dt = Temporal.PlainDateTime.from("2025-01-25T00:00Z")
    Uncaught RangeError: Z designator not supported for PlainDateTime
        ToTemporalDateTime ecmascript.mjs:1198
        from plaindatetime.mjs:286
         debugger eval code:1

Re: JavaScript Temporal Is Coming

#20

Post by burntsushi »

proc0 wrote: post #7

Wondering why not use Time instead. Also the use of "plain" in some of those methods, who is coming up with the names, they are verbose. That said it's probably going to be wrapped in some module anyway.

It's good that the "plain" data types are verbose. Because those should be less commonly used.
Post reply on HN