Temporal: The 9-year journey to fix time in JavaScript

jon_kuperman

What a journey!

bnb

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

samwho

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

virgil_disgr4ce

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

normie3000

No mention of JodaTime?

sharktheone

Very happy for it finally being there!

nekevss

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 :)

plucas

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?

zvqcMMV6Zcr

> Safari (Partial Support in Technology Preview) Safari confirmed as IE Spiritual successor in 2020+.

redbell

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

ChrisArchitect

A good article and discussion from January: Date is out, Temporal is in https://news.ycombinator.com/item?id=46589658

ChrisArchitect

Aside: Bloomberg JS blog? ok.

philipallstar

> 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?

VanCoding

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.

hungryhobbit

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();

darepublic

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

kemayo

> 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.

wpollock

> "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!

NooneAtAll3

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

SoftTalker

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.