Temporal shipped backwards

I have spent years installing date-fns on reflex, the way you grab a coat before checking the weather. Native Date is unusable for anything past "what time is it right now," so you pull in a library, pin a version, move on. Temporal was always the promised fix, perpetually a couple of years out.

It stopped being a promise in March, when TC39 pushed the proposal to Stage 4 after nine years of work, locking it into ECMAScript 2026.

The order is the story

The shipping itself is not the interesting part. Normally the browser leads on new syntax, V8 and SpiderMonkey ship it, and Node picks it up a release or two later running an older engine snapshot. Temporal flipped that.

Node 26 landed in May with Temporal enabled by default, no flag needed. Chrome had it since January, Firefox since May last year. Safari is still sitting behind a flag in Technical Preview, with no committed release date.

Your API server can use the new API today with zero dependencies. Your frontend code, if it needs to run on an iPhone, still cannot.

What it fixes

const now = Temporal.Now.instant();
const later = now.add({ hours: 2 });

No mutation. No guessing which timezone new Date(dateString) silently assumed on your behalf. That is the whole pitch, and it holds up in practice.

My favorite example of the old pain is the one-liner every JS developer has been bitten by. new Date('2026-07-24') quietly parses as UTC midnight, so anyone west of Greenwich renders July 23. The same date with slashes instead of hyphens parses as local time, because of course it does. Temporal refuses to play that game. Temporal.PlainDate.from('2026-07-24') is a calendar date, full stop, no timezone attached, and it can never drift a day depending on who is looking at it.

There is a separate type for each concept:

• PlainDate for a calendar date that belongs to no timezone at all.
• PlainTime for a wall-clock time.
• ZonedDateTime for when a timezone genuinely belongs to the data.
• Instant for a point on the global timeline.

Half the value of Temporal is not the arithmetic. It is being forced to say which of these you actually mean, the thing Date let us stay vague about for thirty years.

What to do today

The pragmatic move is not "migrate everything now" or "wait for Safari." It is splitting by where the code actually runs. Backend logic, cron jobs, anything that never touches a browser: use Temporal and delete the date-fns dependency, today, for free.

Anything client-facing still needs the temporal-polyfill package until Safari ships, which at WebKit's current pace could be next year or the one after. Reach for the lean production build from FullCalendar, not @js-temporal/polyfill, which is the champions' spec-reference build meant for tests.

The migration itself will be boring in the good sense. The polyfill implements the same shape as the native API, so when Safari finally catches up, you delete one import line and nothing else in the codebase changes. That is what a platform feature is supposed to feel like: invisible while it is rolling out, forgettable once it is done.