Contact emails
ft...@chromium.org, manis...@google.com, les...@google.comExplainer
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>APIWeb Feature ID
temporalSearch tags
date, time, Temporal, RustTAG review
This is an ECMA/TC39 feature and does not fall under W3C TAG.TAG review status
Not applicableRisks
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/498WebKit: 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 isYesThis 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-harmonyFinch feature name
NoneNon-finch justification
This is a V8/JS featureRollout plan
Will ship enabled for all usersRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/v8/issues/detail?id=11544Estimated 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