Intent to Ship: Temporal in ECMA262

[Manish Goregaokar]

Contact emails

ft...@chromium.org, manis...@google.com, les...@google.com

Explainer

https://tc39.es/proposal-temporal/docs/
https://tc39.es/proposal-temporal/

Specification

https://tc39.es/proposal-temporal/

Summary

Temporal API https://github.com/tc39/proposal-temporal in ECMA262 is a new API that provides standard objects and functions for working with dates and times. Date has been a long-standing pain point in ECMAScript. This proposes Temporal, a global Object that acts as a top-level namespace (like Math), that brings a modern date/time API to the ECMAScript language. For a detailed breakdown of motivations, see: https://maggiepint.com/2017/04/09/fixing-javascript-date-getting-started/

Blink component

Blink>JavaScript>API

Web Feature ID

temporal

Search tags

date, time, Temporal, Rust

TAG review

This is an ECMA/TC39 feature and does not fall under W3C TAG.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Temporal allows for calendar implementations to differ in specifics. All current implementors except for Safari use ICU4X for their non-ISO calendar implementations. Safari doesn't appear to support the non-ISO part of the spec yet. Generally, this type of incompatability is expected behavior, and if not ICU4X, Safari's implementation would likely use ICU4C which is in alignment with ICU4X for modern dates.

Gecko: Shipped/Shipping (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#browser_compatibility) https://github.com/mozilla/standards-positions/issues/498

WebKit: In development (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#browser_compatibility) Safari's implementation is a very old version of the spec, and is very partial.

Web developers: No signals

Other signals:

Ergonomics

This will be used in tandem with the Date and Intl APIs. There is no thread affinity for this API.

Activation

There are already polyfills and MDN docs out there. This library is designed to be directly usable by devs.

Security

This library calls into ICU4X, a Rust library, which might improve the safety of the code. However the (autogenerated, tested) FFI layer may have bugs. Overall it should not be much less secure than

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None

Debuggability

This suffices with "basic tooling", this is a JS API.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

YesThis feature is supported on all platforms with Rust support, which includes all Chrome platforms. There are some V8 platforms this is

Is this feature fully tested by web-platform-tests?

YesThis is fully tested in test262. https://test262.fyi/#built-ins/Temporal Note that test262 shows a low percentage passing because of a bug in their infra (https://github.com/test262-fyi/data/pull/110). Locally we pass 99%.

Flag name on about://flags

enable-javascript-harmony

Finch feature name

None

Non-finch justification

This is a V8/JS feature

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=11544

Estimated milestones

Shipping on desktop	144
Shipping on Android	144

Note: There is a small chance this API will be able to ship in Chrome 143, but we are not aiming for that.

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5668291307634688?gate=5961362258264064

This intent message was generated by Chrome Platform Status.

[Alex Russell]

LGTM1; thank you for making this happen.

On Thursday, September 25, 2025 at 8:29:29 AM UTC-7 Manish Goregaokar wrote:

Contact emails

ft...@chromium.org, manishearth...@google.com, leszeks@google.com

[TAMURA, Kent]

LGTM2

On Tue, Sep 30, 2025 at 3:22 AM Alex Russell <sligh...@chromium.org> wrote:

LGTM1; thank you for making this happen.

On Thursday, September 25, 2025 at 8:29:29 AM UTC-7 Manish Goregaokar wrote:

Contact emails

ft...@chromium.org, manis...@google.com, les...@google.com

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5a902787-a54c-4c9e-88b0-30f5894d2e74n%40chromium.org.

--

TAMURA Kent
Software Engineer, Google

[Dan Clark]

LGTM3

[Philip Jägenstedt]

Since I've been working on ICU and date formatting, I have a question about how that affects Temporal.

What is the API for formatting a Temporal object in a specific locale, equivalent to new Intl.DateTimeFormat("en").format(date)?

Does the workaround to replace NNBSP with an ASCII space apply also to Temporal? I would like to test this in Chrome Canary and Firefox to see that behavior is aligned, and ideally that we don't change the strings since this is a new API without the same site compat constraints.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/900acb4b-edc7-4e87-9a6b-b51c174412c8n%40chromium.org.

[Manish Goregaokar]

> What is the API for formatting a Temporal object in a specific locale, equivalent to new Intl.DateTimeFormat("en").format(date)?

Exactly the same, with a Temporal object instead of a Date. There is also temporalDate.toLocaleString("en", {options}), but that just calls Intl.DateTimeFormat under the hood.

A small difference is that when you use a Temporal type it autodetects the type of date formatting requested: so if you're formatting a PlainTime it will only format a time, etc.

> Does the workaround to replace NNBSP with an ASCII space apply also to Temporal? I would like to test this in Chrome Canary and Firefox to see that behavior is aligned, and ideally that we don't change the strings since this is a new API without the same site compat constraints.

It would currently apply the same workaround, there is no new formatting code introduced by Temporal, it all just uses DateTimeFormat. You should be able to enable `harmony` under chrome://flags to test Temporal in Canary (maybe even release at this point?).

I know that ICU4C was considering exposing a toggle for the NBSP behavior, I'm not sure if that's happened yet. If ICU4C has it, Chrome could set it to "use NBSP" when formatting Temporal types. If that API doesn't exist yet we may still be able to make that change eventually; I have a hard time seeing people parsing formatted Temporal dates the way they did with Date because the whole point of those parse hacks was to do time zone/etc computations that Temporal exposes directly.

Thanks,

-Manish