This tracker covers the JavaScript Temporal date and time API (not the Temporal workflow engine). A row counts as stable only when a release build exposes the Temporal global with no flag, opt-in or preview channel. TypeScript is tracked for its built-in types, and the two npm polyfills are tracked because they are what you ship to engines that lack it. Engineers check this before deleting a date library or a polyfill: the answer differs between the browser your users run, the server you deploy to and the phone app your team also maintains. Read the version column as the first release with that status. Every row was opened at its primary source on its lastChecked date, and rows marked as tested were also run on our machine with the version named in the note.

Important Notes

Safari ships the engine code but not the global

None of the Safari 27.0, 27.1 or 27.2 release notes add Temporal; 27.0 only lists a fix to Temporal.Instant operations. On macOS 27.0.1, the system JavaScriptCore that Safari 27.0.1 uses printed typeof Temporal: undefined. Running the same jsc binary with --useTemporal=true exposed a working implementation, so the code is in the shipping engine with the switch off. Safari on iOS has no Technology Preview build, and MDN's compatibility data lists it as unsupported.

Bun runs on JavaScriptCore and turns that switch on by default from 1.4.0, which is why a JavaScriptCore-based runtime is stable here while Safari is not.

Temporal API polyfill: which package

The two npm polyfills behave differently. @js-temporal/polyfill is import-only: on Node 24.22.1 it returned correct results and left globalThis.Temporal undefined, so code written against the global keeps failing. Its README still lists a production release as an open roadmap item, and its last publish was 0.5.1 in March 2025.

temporal-polyfill 1.0 installs the global and, since 1.0, uses native Temporal when the engine has it. The README's entrypoint:

import 'temporal-polyfill/global' // most common entrypoint

Version 1.0 dropped CommonJS (ESM and a global IIFE only), and calendars other than iso8601 and gregory need a different entrypoint, so apps that format non-Gregorian dates should check their imports before moving to 1.0.

TypeScript needs the esnext.temporal lib

TypeScript 6.0 added the types, but only under --target esnext, "lib": ["esnext"] or the narrower esnext.temporal. A project on es2025 libs fails on TypeScript 7.0.2 with:

t.ts(1,10): error TS2503: Cannot find namespace 'Temporal'.

Adding esnext.temporal next to es2025 compiled cleanly in our test. That is the smaller change if you do not want every other esnext type. The types say nothing about the runtime: in Safari 27.0.1, typeof Temporal is still undefined without a polyfill.

Cloudflare Workers: opt in with the temporal flag

On Cloudflare's edge runtime, Temporal sits behind the temporal compatibility flag, which turns on by default for compatibility dates of 2026-12-01 or later (no_temporal turns it off). Because the runtime removes both the global and Date.prototype.toTemporalInstant when the flag is off, feature detection gives a clean answer rather than a half-present API. With workerd 2026-11-07 and a 2026-11-01 compatibility date, the global was undefined without the flag and worked with it. Cloudflare also aligned Temporal.Now with Date.now(). We did not deploy to Cloudflare's production network.

Node.js: version 26, and custom builds can drop it

Official Node 26 binaries include Temporal, and what that default means for existing Date code has its own write-up. Node's configure script has a --v8-disable-temporal-support option, and the 26.0.0 changelog added cargo and rustc checks for Temporal, so a distro or internal build can be configured without it. Check typeof Temporal inside your production image.

On Node 24.22.1 the V8 flag --harmony-temporal exposed a working global in our test. V8 flags are not a supported Node option; for anything below 26, use a polyfill.

Bun: opt-out switch and test equality

Setting BUN_JSC_useTemporal=0 made our probe print typeof Temporal: undefined on 1.4.0. The change to watch is in testing: 1.4.0 also changed toEqual(), toStrictEqual() and Bun.deepEquals() to compare Temporal objects by value. Before 1.4.0, any two instances of the same class compared equal, so a test asserting two different PlainDate values could pass. Date-heavy suites that passed on an earlier Bun deserve a second run on 1.4.0.

React Native on Hermes

Hermes's feature list puts Temporal among the newer standard-library additions it does not implement. The feature list gives no plan or timeline, so the row is not marked planned. Of the two polyfills, temporal-polyfill is the one that installs the global that code written for Node or Chrome expects.

Spec status: Stage 4, expected in ES2027

TC39 moved Temporal to Stage 4 at its March 2026 meeting, and the committee's finished-proposals list gives 2027 as the expected publication year. In May 2026 the spec text still sat in open pull requests against ECMA-262 and ECMA-402, awaiting editor review.

Methodology

A browser or runtime is stable when its vendor's release notes say Temporal is supported or enabled by default in a release build. Experimental covers a preview channel (Safari Technology Preview), an opt-in flag (Workers) and a project that calls itself alpha (@js-temporal/polyfill). TypeScript is stable from the release whose notes announce the types; polyfills are stable from a 1.0 release. The site's status set has no "not supported" value, so Hermes shows unknown and its note says why. When a source sat between two statuses, we picked the less mature one.

The contender list started from the support keys in MDN's browser-compat-data entry for Temporal, the caniuse browser list, the polyfills linked from the TC39 proposal, and a search of the Cloudflare workerd and Hermes repositories. Excluded:

  • Opera, Samsung Internet, Chrome for Android and Android WebView: Chromium builds with no vendor note on Temporal. caniuse lists Samsung Internet up to 31 as unsupported, so their status depends on which Chromium version they carry.
  • Vercel and Netlify edge functions: neither publishes the engine version per release or a Temporal statement.
  • Boa, QuickJS and other embeddable engines: rarely a deployment target for this page's readers.
  • Older Temporal polyfills: deprecated by the @js-temporal project in favour of its own package.

Firefox for Android and Safari on iOS are folded into the Firefox and Safari rows.

Hands-on checks ran on macOS 27.0.1 on 2026-11-07 with a small probe script per environment: each reads typeof Temporal, adds an hour across the UK daylight-saving change (2026-03-29T01:30[Europe/London] became 03:30+01:00 in every engine that had Temporal), and, in Bun 1.4.0, Node 26.13.0 and Deno 2.9.6, computes the gap from 2026-01-31 to 2026-03-01 in months, which all three returned as P1M1D. Tested: Bun 1.4.0, Chrome 156, Deno 2.9.6, Firefox Developer Edition 159, Node 26.13.0 and 24.22.1, TypeScript 7.0.2, both polyfills, workerd 2026-11-07 and the Safari 27.0.1 system JavaScriptCore. Edge and Safari Technology Preview were not installed, so those rows rest on release notes, as does Hermes.

Rows are re-verified at least every 30 days. A row whose source can no longer be confirmed moves to unknown instead of disappearing.

Related Content