Progress update

Temporal is shipping in Firefox Nightly builds. Some open questions have been raised about coordinating locale-defined behaviour between implementations, which TG2 is addressing. We will continue to analyze code coverage metrics, submit additional
test262 tests, and answer any questions raised.

Test conformance as of April 2025

Internal calculations

In the past there were performance concerns about the use of BigInts in the spec. I showed in a previous update that 75 integer bits were enough.

Based on a paper¹, I wrote a proof of concept representing epoch nanoseconds and time durations as a pair of 64-bit floats each, so that you don't have to deal with nonstandard-sized integers. Let me know if interested for your implementation.

¹ Hida, Li, Bailey (2008). Library for double-double and quad-double arithmetic. Technical report, Lawrence Berkeley National Laboratory. https://www.davidhbailey.com/dhbpapers/qd.pdf

Proposed summary for notes

ILD

Implementation- and locale-defined.

new Date().toLocaleString('en', { dayPeriod: 'long' })
// → "in the afternoon"

iii. Let fv be a String value representing the day period of tm in the form given by f; the String value depends upon the implementation and the effective locale of dateTimeFormat.

Stability in ILD behaviour

It's good for users of the web when...

• ILD behaviour is stable, so that websites don't break
• ILD behaviour is updated to follow changing cultural practices & better understanding thereof, so that websites are localized in a way that makes users comfortable

These two things are both good, and directly in tension

Test coverage

• Should it be a goal to cover every combination of locale and options?
• IMO, no!
• Diminishing returns, after a certain point you are just testing CLDR

Some existing strategies for ILD testing

(that are not ideal)

• "Golden" output
• "Mini-implementation"

Golden output

• Testing jargon: comparing output of method under test to known-good output
• Undesirable in test262 because:
  • golden output varies between implementations
  • golden output varies over time
  • variations are permitted by specification
  • test suite can only reasonably be run by an implementation using a specific version of CLDR, and if you aren't using CLDR, forget it

Mini-implementation

• Including what is essentially a polyfill in the test, comparing its output to that of method under test
• Undesirable in test262 because:
  • difficult to understand what's being tested
  • unclear whether the polyfill or implementation is at fault when tests fail

But what to do instead?

• Stable substrings?
• Comparative testing?
• Metamorphic testing?

Stable substrings?

• Not golden output, but a part of the output that is reasonably expected to be stable
• More robust than golden output
• Still shares some disadvantages

const formatter = new Intl.DateTimeFormat("en", { dateStyle: "full" });
const result = formatter.format(new Date(2024, 9, 24, 12));
assert(result.indexOf("October") > -1);

Comparative testing?

• Each setting for an input option must produce a distinct output
• Could be good for getting coverage
• Assumption doesn't hold in all cases

const date = new Date(2024, 9, 24, 12);
const weekdayResults = ["narrow", "short", "long"].map((weekday) => date.toLocaleString("en", { weekday }));
assertNoDuplicates(results);

// BUT:
const dayResults = ["numeric", "2-digit"].map((day) => date.toLocaleString("en", { day }));
assertNoDuplicates(dayResults); //  fails for days ≥ 10

Metamorphic testing?

• Find invariant properties of outputs that must hold across multiple inputs
• No need to specify what those outputs exactly are
• Can be difficult to find these properties if not specified

const locale = /* any locale, with any calendar or any numbering system */;
const date = new Date(2024, 9, 24, 12);
const dayString = date.toLocaleString(locale, { day: "numeric" });
const monthName = date.toLocaleString(locale, { month: "long" });
const fullDateString = date.toLocaleString(locale, { dateStyle: "full" });
assert(fullDateString.indexOf(dayString) > -1);
assert(fullDateString.indexOf(monthName) > -1);

Discussion

• Further thoughts welcome!
• What kind of guidelines would be helpful for implementations?
• More info: https://github.com/tc39/test262/issues/3786

Proposed summary for notes