Temporal: JavaScript Finally Fixes Dates

a month ago by codeinabox to c/javascript

Temporal shipped in Chrome 144 and hit TC39 Stage 4. Immutable types, real timezone support, and no more zero-indexed months. Here's why it finally replaces Date.

dan 5 points a month ago

It's a pretty good API. I recently built an appointment booking form and used Temporal for it. Thankfully, all the date logic is server-side (in server-side actions on an Astro site) so I didn't have to worry about browser compatibility.

I just have a few small nitpicks, but they're pretty easily fixable by using my own classes that extend the standard Temporal ones, or just standalone functions. Some examples:

I wish the classes like Date, DateTime, ZonedDateTime, etc had methods like isBefore and isAfter to compare to another instance. For some reason, I can never remember whether compare returning a negative number means the first argument is less than or greater than the second one. Maybe one day we'll get operator overloading.
I wish there was a way to set the default calendar. I had to manually pass calendar: 'gregory' in a bunch of places because I ended up hitting issues without it (one example). My code isn't running outside of areas that use the Gregorian calendar, so setting it as a default in my code would be ideal.

Node support was a bit rough in June/July so I ended up using the polyfill, but I think they've fixed all the major issues now.

save

path: 0 25617184, hotness: undefined, score: 5, children: 0

BrianTheeBiscuiteer 4 points a month ago

Not that it fixes everything but we'd have fewer ulcers in the world if we just stored every date in UTC and only converted when a human looks at it.

save

path: 0 25619320, hotness: undefined, score: 4, children: 1

dan 3 points a month ago

That's what Unix time is... kind of. It's what's usually referred to as an "instant", which is a moment in time that's independent of any timezone or calendar. It's just a plain number that increments by 1 every second.

A lot of systems already store dates and times as Unix timestamps, which means they're already timezone-independent and the timezone and formatting are only applied when rendering it.

In some cases, you do actually need to know the timezone. Calendar events are a good example - an event may end in a different timezone than it starts in (like if the event involves travelling), so both timestamps need their own timezone.

There's also cases where there's no 1:1 mapping between a date/time and a Unix time. Daylight saving is the best example. When the clock moves forward from 2am to 3am, the times between 2am and 3am don't have a Unix time, because they don't actually exist. Conversely, when the clock moves from 2am back to 1am, the times between 1am and 2am have two Unix times - one before the change and one after the change.

That's not to mention outliers like Antarctica where each research base chooses its own timezone.

Dates and times are very complicated :)

save

path: 0 25619320 25627732, hotness: undefined, score: 3, children: 0