Art 19 ↔ Art 25 — Free expression in technical standards may prioritize developer productivity (Article 19) over the material welfare of users (Article 25) when financial systems depend on those standards; the content resolves this by framing timestamp correctness as supporting both freedoms and financial system integrity.

bnb 2026-03-11 15:46 UTC link

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

nekevss 2026-03-11 16:11 UTC link

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 2026-03-11 16:13 UTC link

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 2026-03-11 16:20 UTC link

> Safari (Partial Support in Technology Preview)

Safari confirmed as IE Spiritual successor in 2020+.

redbell 2026-03-11 16:36 UTC link

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

VanCoding 2026-03-11 16:56 UTC link

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.

kemayo 2026-03-11 17:31 UTC link

> 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 2026-03-11 17:33 UTC link

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

xp84 2026-03-11 18:25 UTC link

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

the__alchemist 2026-03-11 19:05 UTC link

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)

alanning 2026-03-11 19:48 UTC link

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

Animats 2026-03-11 21:00 UTC link

I went through a similar decade-long fire drill around ISO8601 date parsing in Python.[1] Issue started in 2012, and after about a decade a solution was in the standard library.

[1] https://groups.google.com/g/comp.lang.python/c/Q2w4R89Nq1w

Vinnl 2026-03-11 21:44 UTC link

> Whilst Firefox was able to implement Temporal as it was being specced - thanks to the great work of André Bargull (known online as Anba)

It's worth highlighting that André is actually a volunteer contributor who managed to implement the whole thing by themselves.

tmpfile 2026-03-11 22:51 UTC link

I’d like to have interval types for example

   const D = new Temporal()
   const t = new Interval({minutes:5})
   const v = D.add(t)

wesselbindt 2026-03-11 22:56 UTC link

I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug any day of the week.

QGQBGdeZREunxLe 2026-03-12 00:49 UTC link

Noticed that converting between certain calendars is not supported. Was that choice intentional?

    const today = Temporal.PlainDate.from("2569-03-11[u-ca=buddhist]"); 
    today.toLocaleString("en", { calendar: "hebrew" });
    > Uncaught RangeError: calendars "buddhist" and "hebrew" aren't compatible

FireBeyond 2026-03-12 01:27 UTC link

> Higher-precision timestamps (nanoseconds, at a minimum)

I get HFT, but I have a hard time comprehending a need for a Bloomberg Terminal to be talking in picoseconds, as in fractions of a billionth of a second.

avandecreme 2026-03-12 07:28 UTC link

I didn't know about https://docs.rs/temporal_rs/latest/temporal_rs/

I wonder if it has a chance to replace chrono and jiff in the rust ecosystem.

corentin88 2026-03-12 07:44 UTC link

Temporal is a good idea, but the API is too complicated for broad adoption:

- new Date() equivalent in Temporal is `const now = Temporal.Now.zonedDateTimeISO();`.

- Date.now() equivalent is `Temporal.Now.instant().epochMilliseconds`

- It’s PascalCase, where JS is mostly snakeCase.

- nanoseconds per default. who needs that except Bloomberg? It should have been an option

It’s definitely great all the efforts put in place, but it’s not going to be a replacement to Date which such a complicated design.

matheus-rr 2026-03-12 14:27 UTC link

The Java parallel is apt. Joda-Time dominated the ecosystem for about 8 years before JSR 310 landed in Java 8 (2014). One thing that helped there was a clear, single release target.

What I keep thinking about with Temporal is the adoption timeline question isn't really 'is it specced?' anymore, it's 'what minimum runtime version do I need?' Node.js, Deno, Bun all need to ship it stably, and then the practical floor for usage is wherever most prod environments are. The polyfill situation (@js-temporal/polyfill and others) doesn't really collapse until that happens.

So the speccing is done but I think we're still a couple of LTS cycles away from it being genuinely boring to reach for Temporal.

apaprocki 2026-03-11 15:55 UTC link

Node 26! Only a matter of time... :)

apaprocki 2026-03-11 16:20 UTC link

I would characterize it more as Joda likely informed Moment.js, which better informed TC39 because it was within the JavaScript ecosystem. As we discussed in plenary today when achieving consensus, every programming language that implements or revamps its date time primitives has the benefit of all the prior art that exists at that instant. TC39 always casts a wide net to canvas what other ecosystems do, but isn't beholden to follow in their footsteps and achieves consensus on what is best for JavaScript. So my view is this more represents what the committee believes is the most complete implementation of such an API that an assembled group of JavaScript experts could design over 9 years and finalize in 2026.

cubefox 2026-03-11 16:35 UTC link

2026 A.D., still no support for native date pickers in mobile Safari.

CharlesW 2026-03-11 17:05 UTC link

FWIW, I've been using it server-side via the js-temporal polyfill for some time, no issues.

mrkeen 2026-03-11 17:06 UTC link

Yep, JavaScript got the bad version from Java too!

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

perfmode 2026-03-11 17:14 UTC link

This is a real pain point and I run into the same tension in systems where data crosses serialization boundaries constantly. The prototype-stripping problem you're describing with JSON.parse/stringify is a specific case of a more general issue: rich domain objects don't survive wire transfer without a reconstitution step.

That said, I think the Temporal team made the right call here. Date-time logic is one of those domains where the "bag of data plus free functions" approach leads to subtle bugs because callers forget to pass the right context (calendar system, timezone) to the right function. Binding the operations to the object means the type system can enforce that a PlainDate never accidentally gets treated as a ZonedDateTime. date-fns is great but it can't give you that.

The serialization issue is solvable at the boundary. If you're using tRPC or similar, a thin transform layer that calls Temporal.Whatever.from() on the way in and .toString() on the way out is pretty minimal overhead. Same pattern people use with Decimal types or any value object that doesn't roundtrip through JSON natively. Annoying, sure, but the alternative is giving up the type safety that makes the API worth having in the first place.

WorldMaker 2026-03-11 18:03 UTC link

Deno has had it behind the `--untable-temporal` flag for quite a few Minor versions now and the latest Minor update (because of TC-39's Stage 4 acceptance and V8 itself also marking the API as Stable) removed the requirement for the flag and it is out of the box.

WorldMaker 2026-03-11 18:18 UTC link

Slower to implement new features, but still implementing them, just makes it the new Firefox. IE's larger problem was how popular it had been before it stopped implementing new features. It was like if Google got bored with Chrome and decided to stop all funding on it. People would be stuck on Chrome for years after that investment stopped because of all the Chrome-specific things built around it (Electron, Puppeteer, Selenium, etc and so forth).

Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back". Safari's problems are temporary. Chrome is the new Emperor and IE wasn't bad because it stopped, it was bad because it stopped after being the Emperor for some time. People remember how bad the time was after the Empire crumbled, but it's how IE took so many other things down with it that it is easier to remember the interregnum after IE crumbled than to remember the heyday when "IE-only websites are good enough for business" sounded like a good idea and not a cautionary tale.

jayflux 2026-03-11 18:51 UTC link

This was an intentional design decision. We wanted to make sure all the temporal types could be serialize/deserializable, but as you mentioned, you couldn't implicitly go back to the object you started with as JSON.parse doesn't support that.

Instead the onus is on the developer to re-create the correct object they need on the other side. I don't believe this is problematic because if you know you're sending a Date, DateTime, MonthDay, YearMonth type from one side, then you know what type to rebuild from the ISO string on the other. Having it be automatic could be an issue if you receive unexpected values and are now dealing with the wrong types.

There is an example here in the docs of a reviver being used for Temporal.Instant https://tc39.es/proposal-temporal/docs/instant.html#toJSON

TimTheTinker 2026-03-11 20:52 UTC link

Updating JSON.parse() to automatically create Temporal objects (from what shape of JSON value?) without a custom reviver would be a step too far, in my opinion.

This is effectively no different from Date:

  serialize: date.toJSON()
  deserialize: new Date(jsonDate)

in Temporal:

  serialize: instant.toJSON()
  deserialize: Temporal.Instant.from(jsonDate)

apaprocki 2026-03-11 21:08 UTC link

Yes, please try! One of the main motivations for doing all this work is to slim down both the amount of code that has to be delivered and executed by providing everything that's needed by the platform. In addition, you're slimming the potential bug/attack surface as well, which is always nice.

baliex 2026-03-11 21:21 UTC link

Thank you thank you thank you.

Parsing dates with anything other than fromisoformat feels totally backwards in comparison. We were using ciso8601 until fromisoformat was in the standard library. And now things are incredibly simple and reliable.

tshaddox 2026-03-11 22:35 UTC link

Don’t JavaScript Date instances have the same problem? Date implements toJSON, but when parsing JSON you’ll have to manually identify which string values represent Dates and convert them back to Date instances. The exact same is true of Temporal (e.g. Instant).

And as far as I know, date-fns deals with native Date instances, not “data-only objects.”

nikeee 2026-03-11 23:34 UTC link

It is called Duration.

throwaway_12629 2026-03-12 00:13 UTC link

Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.

plastic041 2026-03-12 00:34 UTC link

That's Duration!

    const D = Temporal.PlainDate.from("2020-06-16");
    const t = Temporal.Duration.from({ day: 1 });
    const v = D.add(t) // 2020-06-17

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

rmunn 2026-03-12 01:02 UTC link

Converting between solar-based and lunar-based calendars is fraught with potential for ambiguity. The Buddhist calendar is a solar calendar, while the Hebrew calendar is lunar-based. So converting between dates in the Buddhist calendar and the international-standard (ISO 8601) calendar is typically easy (give or take some subtleties I won't go into for reasons of length). But converting between the Hebrew calendar and the ISO 8601 calendar, or the Buddhist calendar, involves figuring out when the new moon will be — and since the lunar cycle is 29 or 30 days, 12 lunar months add up to 354 days. So the lunar calendars, including the Hebrew calendar, typically add a "leap month" every two or three years in order to track the sidereal year.

All of which means there are many potential ambiguities in converting between calendars, and the combinatorial explosion possible means they probably only want you to convert between non-ISO8601 calendars and ISO8601. It would be too easy to get corner cases wrong otherwise and not notice, I'm sure. So to convert a date from Buddhist calender to Hebrew calender, you'd probably have to do Buddhist -> ISO8601, then ISO8601 -> Hebrew. (I haven't had time to test that for myself yet, I'll post a correction if that turns out to be wrong).

SOLAR_FIELDS 2026-03-12 01:18 UTC link

In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?

paradox460 2026-03-12 01:39 UTC link

Certainly surprising

One of my favorite interview questions is asking a candidate to, piece meal, build a calendar. They start with Julian, and then write converters to and from other calendars. Any calendar can be converted to any other, by going through Julian

I got the idea from the book "calendrical calculations"

nulltrace 2026-03-12 02:50 UTC link

The serialization thing is real but I don't think OOP vs functional is the actual issue here. JSON has no date type, period. You JSON.stringify a Date, get an ISO string, and hope whoever's parsing remembers to reconstruct it. Temporal doesn't fix that part, but at least when you do reconstruct you're saying "this is a ZonedDateTime" vs "this is an Instant" instead of everything being one ambiguous Date object.

sfink 2026-03-12 03:07 UTC link

Considering how prolific anba is, the only way we know he isn't an LLM is because he'd have to be several generations more advanced than the current SOTA. (It is possible that he might be an LLM from a few decades in the future, considering the connection to Temporal.)

anba implemented all of Temporal single-handedly, plus fixed up numerous places in the spec, plus migrated the implementation over some massive changes after other implementers discovered what a monster it all is. The original version of the spec kind of forced two separate internal implementation paths for everything, one for custom calendars and one for the built-in stuff, just to make the built-in one reasonably performant. That was a lot of work to implement, and a lot of work to remove. (I think ptomato shepherded the spec side of that?)

Fortunately, anba knows how to take a break, relaxing occasionally with minor tasks like rewriting large swathes of the JIT code generator to optimize the support on various platforms. He also gets plenty of nutrition, by ingesting entire specs and mind-melding with them.

jitl 2026-03-12 04:48 UTC link

I wouldn't be surprised to see the Rust ecosystem eventually move to Temporal's api, given v8 (Chrome) adopted Boa's rust implementation temporal_rs (https://docs.rs/temporal_rs/latest/temporal_rs/), see burntsushi's arguments for the need of a better datetime handling library in Rust (https://github.com/BurntSushi/jiff/blob/master/DESIGN.md#why...). I'm not sure his jiff create will be the one, i think temporal_rs has become the authoritative implementation.

anowell 2026-03-12 04:51 UTC link

Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases.

npmjs.com/package/temporal-fun

fabon 2026-03-12 06:51 UTC link

I think this is intentional design. Anyway we can convert `Temporal.PlainDate` to other calendars explicitly (I believe explicitness is good here).

  today.withCalendar('hebrew').toLocaleString("en", { calendar: "hebrew" });
  // "22 Adar 6329"

Griffinsauce 2026-03-12 07:14 UTC link

An example that is hard to follow defeats the point. It's just showing what pattern is possible and you can imagine the abstraction layers and indirection that would make it happen accidentally.

mexicocitinluez 2026-03-12 12:13 UTC link

I'm in the C# world and can attribute most of my understanding about dates and times to Noda (the .NET version of Joda). Shout out to Jon Skeet for maintaining it.

nekevss 2026-03-12 16:36 UTC link

Yep, temporal_rs is designed with native Rust use in mind, so you should be able to use temporal_rs directly wherever you'd use jiff or chrono.

That being said, the library is designed to be specification conformant and with EcmaScript implementations in mind. There are some specific API choices made specifically for those clients.

That being said, we are always looking for feedback regarding the native Rust API. So feel free to try temporal_rs out and provide whatever feedback you'd like :)

gjm11 2026-03-12 21:30 UTC link

Most of that complication is there because times and dates are actually complicated. You can have a nice simple API that doesn't expose the complication only if you're happy for it to encourage false assumptions and wrong behaviour.

But, still, let's look at your first couple of complaints.

To make #1 more explicit: If you want the equivalent of "new Date()", then as you observe you need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does?

To make #2 more explicit: If you want the equivalent of "Date.now()", then as you observe you again need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does?

Well, because as those two examples show there isn't actually an obvious simple thing. Two operations both of which one might expect to do the obvious simple thing do different things, and if there's some obvious way for someone who doesn't already happen to have the specs of Date memorized to know which one is "new Date()" and which one is "Date.now()", I don't know what it is.

So, to me, those first two examples look like pretty convincing evidence that Temporal is a better design and one that's less likely to lead non-experts to make serious mistakes.

... And then your other two complaints aren't actually about the API being "too complicated" at all! PascalCase isn't more complicated than snakeCase. Nanoseconds aren't more complicated than milliseconds.

(Also: "zonedDateTimeISO" and "epochMilliseconds" are in fact both snakeCase, and a quick look at the Temporal documentation suggests that this is the norm. Method names are snakeCase, class names are PascalCase. I am not a Javascript expert but isn't that pretty normal?)

ivankra 2026-03-13 09:15 UTC link

Try `node --harmony-temporal`

Editorial Channel

What the content says

Structural Channel

What the site does