JavaScript Temporal Is Coming

Which browsers are you testing with? AFAIK, the proposal is not final and the impl is pretty much non existent. https://tc39.es/proposal-temporal/docs/

Re: JavaScript Temporal Is Coming

#5

Post by klysm » Fri, Jan 24, 2025, 3:07 AM UTC

ipster_io wrote: post #4

klysm wrote: post #3

I already use it in prod because it is light years better than the alternative

Which browsers are you testing with? AFAIK, the proposal is not final and the impl is pretty much non existent. https://tc39.es/proposal-temporal/docs/

There’s a polyfill

Re: JavaScript Temporal Is Coming

#6

Post by paulryanrogers » Fri, Jan 24, 2025, 3:37 AM UTC

> 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, with 'dangerous' in the type name(s).

Re: JavaScript Temporal Is Coming

#7

Post by proc0 » Fri, Jan 24, 2025, 3:56 AM UTC

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.

Re: JavaScript Temporal Is Coming

#8

Post by mattdw » Fri, Jan 24, 2025, 4:02 AM UTC

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 location - "this event happens at 9am according to whatever timezone is currently in effect in Auckland, NZ". That's a thing that UTC or timezone-aware Datetimes can't help with.

Re: JavaScript Temporal Is Coming

#9

Post by bakkoting » Fri, Jan 24, 2025, 4:02 AM UTC

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 timezone, there's ZonedDateTime.

Re: JavaScript Temporal Is Coming

#10

Post by paulryanrogers » Fri, Jan 24, 2025, 4:14 AM UTC

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…

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 of the merchant location. Using a relative type actually felt like more work because from the merchant perspective, all that mattered was the point in time relative to their zone. It would've been simpler to do the offsetting in the app layer checks. And ultimately no one cared enough to keep maintaining it anyway, having an absolute point in time is usually good enough or even preferred.