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.
Den tis 30 sep. 2025 17:09'Dan Clark' via blink-dev <[email protected]>
skrev:
> LGTM3
>
> On Monday, September 29, 2025 at 8:40:54 PM UTC-7 [email protected]
> wrote:
>
>> LGTM2
>>
>>
>> On Tue, Sep 30, 2025 at 3:22 AM Alex Russell <[email protected]>
>> 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*
>>>> [email protected], [email protected], [email protected]
>>>>
>>>
>>>>
>>>> *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
>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EJavaScript%3EAPI%22>
>>>>
>>>> *Web Feature ID*
>>>> temporal <https://webstatus.dev/features/temporal>
>>>>
>>>> *Search tags*
>>>> date <https://chromestatus.com/features#tags:date>, time
>>>> <https://chromestatus.com/features#tags:time>, Temporal
>>>> <https://chromestatus.com/features#tags:Temporal>, Rust
>>>> <https://chromestatus.com/features#tags: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
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
>>>> 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
>>>> <https://chromestatus.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 [email protected].
>>> To view this discussion visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5a902787-a54c-4c9e-88b0-30f5894d2e74n%40chromium.org
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5a902787-a54c-4c9e-88b0-30f5894d2e74n%40chromium.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>>
>>
>> --
> 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 [email protected].
> To view this discussion visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/900acb4b-edc7-4e87-9a6b-b51c174412c8n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/900acb4b-edc7-4e87-9a6b-b51c174412c8n%40chromium.org?utm_medium=email&utm_source=footer>
> .
>
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYc_dukS0tFyUDFL_zVO4MGMte5zhTq1P7SmMfoB__v6-g%40mail.gmail.com.
