A big step in the right direction, but I still don't like the API, here's why: Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize it easily.

This is not the case for Temporal objects. Also, the temporal objects have functions on them, which, granted, makes it convenient to use, but a pain to pass it over the wire.

I'd clearly prefer a set of pure functions, into which I can pass data-only temporal objects, quite a bit like date-fns did it.

Super happy to see Temporal accepted!

Congrats to all the champions who worked super hard on this for so long! It's been fun working on temporal_rs for the last couple years :)

Would have been interesting to connect back to Java's own journey to improve its time APIs, with Joda-Time leading into JSR 310, released with Java 8 in 2014. Immutable representations, instants, proper timezone support etc.

Given that the article refers to the "radical proposal" to bring these features to JavaScript came in 2018, surely Java's own solutions had some influence?

The Temporal Cookbook on TC39's site provides examples of how using the new API looks/feels:

https://tc39.es/proposal-temporal/docs/cookbook.html

For example, calc days until a future date: https://tc39.es/proposal-temporal/docs/cookbook.html#how-man...

...or, compare meeting times across timezones: https://tc39.es/proposal-temporal/docs/cookbook.html#book-a-...

They travelled through time (forward, at 1X) by nine years to do this for us. I appreciate it.

Maybe I will be able to move away from my custom/minimal DT lib, and ISO-8601 timestamp strings in UTC. JS datetime handling in both Date and Moment are disasters. Rust's Chrono is great. Python's builtin has things I don't like, but is useable. Date and Moment are traps. One of their biggest mistakes is not having dedicated Date and Time types; the accepted reason is "Dates and times don't exist on their own", which is bizarre. So, it's canon to use a datetime (e.g. JS "Date") with 00:00 time, which leads to subtle errors.

From the link, we can see Temporal does have separate Date/Time/Datetime types. ("PlainDate" etc)

> Safari (Partial Support in Technology Preview)

Safari confirmed as IE Spiritual successor in 2020+.

Can't wait for it to land in the server-side runtimes, really the last thing preventing me from adopting it wholesale.

> "It was a straight port by Ken Smith (the only code in "Mocha" I didn't write) of Java's Date code from Java to C."

This is funny to me; Java's util.Date was almost certainly a port of C's time.h API!

> The first proposal I worked on was Promise.allSettled, which was fulfilling.

Har har.

Nine years is a long time, but honestly it tracks with how deeply broken Date has been since Brendan Eich cargo-culted java.util.Date in 1995. The real win with Temporal isn't just immutability or timezone support — it's that PlainDate and ZonedDateTime finally give us types that match how humans actually think about time. I've lost count of how many bugs I've shipped because Date silently coerces everything to UTC instants when half the time what you actually have is a "wall clock" value with no timezone attached.

As a side note, huge fan of Promise.allSettled. When that dropped it cleaned up so much of the code I was writing at the time.

Looking at the caniuse results... f*king Safari (and Opera)...

https://caniuse.com/temporal

From the article:

    const now = new Date();

The Temporal equivalent is:

    const now = Temporal.Now.zonedDateTimeISO();

Dear god, that's so much uglier!

I mean, I guess it's two steps forward and one step back ... but couldn't they have come up with something that was just two steps forward, and none back ... instead of making us write this nightmare all over the place?

Why not?

    const now = DateTime();

> Developers would often write helper functions that accidently mutated the original Date object in place when they intended to return a new one

It's weird that they picked example code that is extremely non-accidentally doing this.

> have to agree on what "now" means, even when governments change DST rules with very little notice.

I didn't spot how Temporal fixes this. What happens when "now" changes? Does the library get updated and pushed out rapidly via browsers?

It's been a while since I worked in JS but dealing with dates/times, and the lack of real integer types were always two things that frustrated me.

Oh, for a second, TeMPOraL (https://news.ycombinator.com/user?id=TeMPOraL) came to my mind!

Thanks for linking to my silly little quiz in the article! :)

Very happy for it finally being there!

interesting point about immutability

No mention of JodaTime?

My playbook for JavaScript dates is.. store in UTC.. exchange only in UTC.. convert to locale date time only in the presentation logic. This has worked well for me enough that Im skeptical of needing anything else

What a journey!

A good article and discussion from January:

Date is out, Temporal is in

https://news.ycombinator.com/item?id=46589658

so Temporal is copying cpp's std::chrono?

Pretty big fan of Temporal. Been using the polyfill for a while. Very nice to use a modern, extremely well thought-through API!

Aside: Bloomberg JS blog? ok.

[flagged]

[flagged]

[dead]

[dead]

[flagged]

[flagged]