Update: We have unflagged Temporal <https://chromium-review.googlesource.com/c/v8/v8/+/7098665>. Barring any unforeseen issues, this ought to ship in Chrome 144 (branch date <https://chromiumdash.appspot.com/schedule> Dec 1).
On Wed, Oct 1, 2025 at 8:34 AM Manish Goregaokar <[email protected]> wrote: > > 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/CAL9OwVzBppmbZddYj4WZM7dW1qOn7H-1vA9qB8yM%3DVqSAWpL_A%40mail.gmail.com.
