> 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
On Wed, Oct 1, 2025 at 1:32 AM Philip Jägenstedt <[email protected]>
wrote:
> 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/CAL9OwVwf20p-5d13ikSJas9ofo7ZYsm%2B949qRkhtvMPxm-J-pg%40mail.gmail.com.
