⌚ Temporal for Stage 4 🎉

Philip Chimento
Igalia, in partnership with Bloomberg
TC39 March 2026

Just in time for Stage 4...

Stage 4 Entrance Criteria

  • Two compatible implementations which pass the Test262 acceptance tests
  • Significant in-the-field experience with shipping implementations, such as that provided by two independent VMs
  • A pull request has been sent to tc39/ecma262 or tc39/ecma402, as appropriate, with the integrated spec text
  • The relevant editor group has signed off on the pull request

Two Implementations Passing Tests

  • Test262 covers every feature, and all the edge cases we've encountered
  • We have 2 implementations at ~100% test conformance

Test conformance as of March 2026

In-the-field Experience

2 browser-based implementations have been shipping Temporal unflagged for several months.

  • SpiderMonkey: May 2025
  • V8: January 2026

Non-browser engines shipping unflagged implementations: Boa, Kiesel, Ladybird.

GraalJS has an implementation, scheduled to be unflagged in 25.1 (no public release date)

In-the-field Experience

Several polyfills exist (figures are gzipped size and weekly downloads):

In-the-field Experience

Shipping Temporal to the web, and having community-authored polyfills, has led to tangible improvements to the proposal during the 5 years of stage 3.

  • Implementors & polyfill authors noticing bugs
  • Implementors & polyfill authors noticing opportunities for improving the spec algorithms
  • Users noticing bugs and surprising edge cases

Thank you for all these contributions!

In-the-field Experience

Shipping Temporal to the web has also enabled automated detection of edge cases and divergences between implementations, by testing each implementation with millions of inputs against snapshots.

  • This has led to filing 19+ bug reports in implementations
    • (and also fixing some of them)
  • Identified many cases for more targeted test262 coverage

This snapshot testing technique was helpful and we recommmend it for smaller proposals too!

Aside: Web Platform Integration

If you want to see this move forward, please express your interest and give use cases on the WHATWG issues!

Pull request to the spec

Editor signoff

  • ECMA-262 Editors:

    • We have discussed the PR in the editor call
    • There is an open question about how to publish the proposal
  • ECMA-402 Editors:

    • TBA

What's next?

  • How should Temporal API & spec text evolve in the future?
  • How should the spec text get integrated into the current 262 spec?

How should Temporal evolve in the future?

  • 5 years of collecting ideas in "Temporal V2" repo
    • 36 ideas, almost all incremental and narrowly scoped
    • Not huge like Temporal
  • Existing champions not eager to run a new TG, but we're happy to:
    • Review/support any follow-up proposals
    • Support fixes to issues found with existing Temporal

How should the spec text get integrated?

  • Stick it in ECMA-262 like any other proposal
  • Give it a separate page in ECMA-262 (would be ECMA-262-2)
  • Make a separate standard (would be "ECMA-430-ish")

ECMA-262 Editors' Slides

Separate standard, TG, editor group

  • arguments in favour of combining
    • discoverability by practitioners
    • 1-time cost of establishing a new Ecma standard
  • arguments in favour of separating
    • doesn't require 262 editor group to maintain expertise
    • having a dedicated TG ensures we maintain experts
    • as with Intl, most of TG1 doesn't care to discuss Temporal details
    • mostly different sets of readers
    • other specs may want to reference just Temporal bits

Separate documents / git repository

  • arguments in favour of combining
    • easier to maintain editorial consistency
    • no obvious place to put shared "infra" AOs
    • shared AOs will prompt normative consistency considerations
    • reduced overhead: 1 CI system, 1 dependency list, etc.
  • arguments in favour of separating
    • reduced single-page load time

ECMA-262 editor group preference

  • strong preference for separate standard and maintainers' groups
  • above implies having separate documents, even though that argument is not as strong on its own

Questions?

Let's discuss topics related to the substance of the proposal before any publishing topics

Requesting consensus for Stage 4

Requesting consensus on ___

Finally, Some Statistics

  • Lines of spec text in ECMA-262: 12k
  • Lines of spec text in ECMA-402: 1.6k
  • Number of merged pull requests: 1.8k
  • Number of champions meetings: almost 200
  • Total word count of champions meeting minutes: 212k
    • That is, number of average-sized novels: 2 to 3

Finally, Some Statistics

How many years since Maggie's kickoff blog post?

Temporal.PlainDate.from('2017-04-09')
  .until(Temporal.Now.plainDateISO(), { smallestUnit: 'months', largestUnit: 'years' })
  .toLocaleString()
  • '8 yrs, 11 mos'

Proposed summary for notes

Firefox nonconformances: two bugs around extreme dates. one around toLocaleString dateStyle formatting in Temporal. In Intl Era, CLDR bug around islamic calendar era names, and bug around East Asian lunisolar reference years Chrome nonconformances: one bug on rounding, one around extreme dates, one on parsing allowing >9 decimal places. a couple around toLocaleString formatting in Temporal. on Intl Era, same CLDR bug, and islamic fallback not handled properly

npx test262-harness --hostType=sm --hostPath=$HOME/.esvu/bin/sm -f Temporal --fe Intl.Era-monthcode "test/**/*.js" npx test262-harness --hostType=sm --hostPath=$HOME/.esvu/bin/sm -f Intl.Era-monthcode "test/**/*.js" npx test262-harness --hostType=v8 --hostPath=$HOME/.esvu/bin/v8 -f Temporal --fe Intl.Era-monthcode -- "test/**/*.js" npx test262-harness --hostType=v8 --hostPath=$HOME/.esvu/bin/v8 -f Intl.Era-monthcode -- "test/**/*.js" npx test262-harness --hostType=libjs --hostPath=$HOME/.esvu/bin/ladybird-js -f Temporal --fe Intl.Era-monthcode --hostArgs=--use-test262-global -- "test/**/*.js" npx test262-harness --hostType=libjs --hostPath=$HOME/.esvu/bin/ladybird-js -f Intl.Era-monthcode --hostArgs=--use-test262-global -- "test/**/*.js" npx test262-harness --hostType=graaljs --hostPath=$HOME/.esvu/bin/graaljs-nightly -f Temporal --fe Intl.Era-monthcode --hostArgs='--experimental-options --js.temporal' -- "test/**/*.js" npx test262-harness --hostType=graaljs --hostPath=$HOME/.esvu/bin/graaljs-nightly -f Intl.Era-monthcode --hostArgs='--experimental-options --js.temporal' -- "test/**/*.js" npx test262-harness --hostType=jsc --hostPath=$HOME/.esvu/bin/jsc -f Temporal --fe Intl.Era-monthcode --hostArgs=--useTemporal=1 -- "test/**/*.js" npx test262-harness --hostType=jsc --hostPath=$HOME/.esvu/bin/jsc -f Intl.Era-monthcode --hostArgs=--useTemporal=1 -- "test/**/*.js" npx test262-harness --hostType=boa --hostPath=$HOME/.esvu/bin/boa-nightly -f Temporal --fe Intl.Era-monthcode -- "test/**/*.js" # requires https://github.com/tc39/eshost/pull/147 and https://github.com/devsnek/esvu/pull/66 npx test262-harness --hostType=boa --hostPath=$HOME/.esvu/bin/boa-nightly -f Intl.Era-monthcode -- "test/**/*.js" npx test262-harness --hostType=kiesel --hostPath=$HOME/.esvu/bin/kiesel-nightly -f Temporal --fe Intl.Era-monthcode -- "test/**/*.js" npx test262-harness --hostType=kiesel --hostPath=$HOME/.esvu/bin/kiesel-nightly -f Intl.Era-monthcode -- "test/**/*.js" npx test262-harness --hostType=node --hostPath=$(which node) -f Temporal --hostArgs=... -- "test/**/*.js" npx test262-harness --hostType=hermes --hostPath=$(which deno) -f Temporal --hostArgs='run --unstable-temporal --v8-flags=--expose-gc' -- "test/**/*.js"

e.g., `epochMicroseconds` and `Array.sumPrecise` are not fundamentally different An analogy could be the relatively recent decision to have a separate TG for Source Maps, which made sense because: * There was a whole new domain that needed better specification * There was needed coordination with many tools vendors who don't normally participate on TG1 * There were fundamental questions about scope The same could have been said about Temporal in 2018, but not anymore. There's no major blank space in the date/time domain remaining that's not covered with APIs. We did string serialization. We did time zones. We did calendars. We did arithmetic. We did a tree of interrelated types. There's no needed external specifications required now that RFC 9557 is ratified. And so on. We had a big job to do, we did it, and now it's time to handle off incremental work to well-established TG1/TG2 committees with well-established processes for handling incremental language changes.