1912511 - Ship Temporal

Status: NEW

(Core :: JavaScript: Standard Library, task, P3)

Description

[Dan Minor [:dminor]]

The temporal champions are asking implementers to consider shipping Temporal. We should at least have a bug on file to do this.

Comment 1

[Dave Letorey]

Related Pull Requests

• Content PR
• BCD PR
• Firefox Experimental release PR

Comment 2

[Tom Schuster]

This can only be complete after this bug is actually fixed and Temporal landed.

Comment 3

[Dan Minor [:dminor]]

Hi Anba, other than fuzzing, do you know of any bugs or spec issues that would block us from being able to ship Temporal?

Comment 4

[André Bargull [:anba]]

There are two open normative PRs, but both are for edge-cases and therefore shouldn't be blockers:

• https://github.com/tc39/proposal-temporal/pull/3054
• https://github.com/tc39/proposal-temporal/pull/3014 (see also https://github.com/tc39/ecma262/pull/3464)

We should decide if we want to implement locale-sensitive Duration.prototype.toLocaleString, even though this isn't currently spec'ed. Users may expect this to work, because the polyfill already implements it:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1942850
• https://bugzilla.mozilla.org/show_bug.cgi?id=1839694#c5
• https://github.com/tc39/proposal-temporal/issues/452#issuecomment-2605404848

We also likely need to add caches for time zones and calendars at some point. Possibly also cache computed calendar fields, so that for example accessing plainDate.year doesn't lead to repeatedly creating new ICU4X date and calendar objects. This probably also falls in the nice-to-have bucket, but isn't a release blocker:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1840424

I think more important are better error messages, because Temporal adds new concepts and APIs to JavaScript, which are possibly unfamiliar to developers. And cryptic error messages could prevent adaption of Temporal. I think it wouldn't hurt if the existing error messages are checked (by a native speaker) to ensure the language is correct and understandable.

• https://bugzilla.mozilla.org/show_bug.cgi?id=1839676

Comment 5

[André Bargull [:anba]]

I forgot to mention ICU4X issues.

1. Dates too far into the past or future aren't yet supported:

• https://github.com/unicode-org/icu4x/issues/4917
• https://github.com/unicode-org/icu4x/issues/5068

2. Islamic to ISO8601 calendar conversion bug:

• https://github.com/unicode-org/icu4x/issues/5069

Example: Temporal.PlainDate.from({year: 1390, monthCode: "M01", day: 30, calendar: "islamic"}).day returns 0.

3. Different start of epoch for Islamic calendar:

• https://github.com/unicode-org/icu4x/issues/4982

That leads to a one day difference when Intl.DateTimeFormat, which uses ICU4C instead of ICU4X.

js> d = Temporal.Now.plainDateISO().withCalendar("islamic")
({})
js> d.month + "-" + d.day                                   
"8-14"
js> d.toLocaleString("en", {calendar:"islamic"})            
"8/15/1446 AH"

In addition to that one-day difference, ICU4X is also using different algorithms to compute dates in the Islamic and Chinese calendars. That leads to returning different results depending on whether ICU4X or ICU4C code is called:

js> d = new Temporal.PlainDate(2027, 2, 6, "chinese")
({})
js> d.month + "-" + d.day
"1-1"
js> d.toLocaleString("en", {calendar:"chinese"})
"12/30/2026"