[meta] Add Intl support for Temporal
Categories
(Core :: JavaScript: Standard Library, enhancement, P3)
Tracking
()
People
(Reporter: anba, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: meta, Whiteboard: [platform-feature])
User Story
platform-scheduled:2025-06-30
Meta bug to cover adding Intl support for the Temporal proposal. Includes:
- Adding support for more calendars besides the ISO-8601 calendar.
- Adding support to format Temporal objects in
Intl.DateTimeFormat. - More?
Time zone support is already provided in the initial patch stack from bug 1519167.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 1•2 years ago
|
||
:anba - now that ICU4X landed (bug 1719535) - would you consider using it for this (over ICU4C)? We believe ICU4X to be way better aligned to Temporal than ICU4C is resulting in much leaner internal code, leaner payload and faster performance.
| Reporter | ||
Comment 2•2 years ago
|
||
It's still the plan to use ICU4X for calendrical computations. Formatting through Intl.DateTimeFormat will still use ICU4C, because Intl.DateTimeFormat uses ICU4C. The next big Temporal tasks are https://github.com/tc39/proposal-temporal/pull/2519 and https://github.com/tc39/proposal-temporal/pull/2612, because both modify internal data structures and execution flow. Calendar support will likely happen after those two PRs are implemented.
Updated•2 years ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 3•1 year ago
|
||
Removing the parity and webcompat risk flags, since Chrome and WebKit haven't actually shipped yet, so the risk is lower than I had assessed earlier.
Comment 4•1 year ago
|
||
Intl.DurationFormat works for Temporal Durations, but toLocaleString() does not work for Temporal Durations in Firefox.
| Reporter | ||
Comment 5•1 year ago
|
||
(In reply to oliverwilliams345 from comment #4)
Intl.DurationFormat works for Temporal Durations, but toLocaleString() does not work for Temporal Durations in Firefox.
Locale-sensitive Temporal.Duration.prototype.toLocaleString isn't yet specified, therefore only the non-locale sensitive version is implemented. It's clear how the specification for the locale-sensitive version should look like, so we could implement it ahead of time, but I don't know if we should implement it without an official spec. (I also don't know when the specification will happen, the tracking issue appears to be https://github.com/tc39/proposal-temporal/issues/452.)
(I'm not sure if this is right place to comment) Since bug 1960300 is resolved now it's ok to enable islamic-umalqura calendar by default? (cf. bug 1912511, comment 22)
Updated•7 months ago
|
Updated•6 months ago
|
Comment 7•6 months ago
|
||
All the dependent bugs are fixed, and we'd likely track issues using the main temporal meta bug, Bug 1839673, so I'm going to mark this as fixed.
Description
•