Tests how Intl.DateTimeFormat formats eras in various calendars. The
actual output is implementation-defined, but we can test a few things:
- Calendars with multiple eras have distinct values for the era part
when formatting dates in each era.
- Calendars with one era have the same value for the era part when
formatting dates with positive and negative era years.
- Calendars without eras do not include an era part in the format.
Some calendars are missing from this test because their era
configurations were updated in CLDR 48. I will add those in a separate
PR which can be merged when implementations have had more time to update
to that version of CLDR.
Co-Authored-By: Philip Chimento <pchimento@igalia.com>
This test calls Intl.DateTimeFormat.prototype.formatToParts() and
format() on dates in lunisolar calendars in leap and non-leap months.
The actual output is implementation-defined so there isn't much specific
that we can test here.
Co-Authored-By: Philip Chimento <pchimento@igalia.com>
Tests the Intl.DateTimeFormat.prototype.resolvedOptions().calendar value
for each supported calendar.
Co-Authored-By: Philip Chimento <pchimento@igalia.com>
As of the Time Zone Canonicalization proposal which is stage 3, the
original time zone name should be preserved in Intl.DateTimeFormat
.prototype.resolvedOptions.
Add a separate test that uses Temporal.ZonedDateTime.prototype.equals
to test the canonicalization behaviour.
The test for https://github.com/tc39/ecma402/pull/724 (added in
https://github.com/tc39/test262/pull/4328) didn't take the Time Zone
Canonicalization proposal into account; but it should, because that
proposal is stage 3.
As of that proposal, the [[TimeZone]] slot of DateTimeFormat gets the
case-regularized original identifier, no longer the primary identifier. So
the resolvedOptions().timeZone property also no longer returns the primary
identifier.
* Add tests to `Intl.DateTimeFormat` and `Intl.RelativeTimeFormat` for formatting in various numbering systems
* fixup! Add tests to `Intl.DateTimeFormat` and `Intl.RelativeTimeFormat` for formatting in various numbering systems
See tc39/proposal-temporal#2795. When attempting to format a Temporal
object, if the DateTimeFormat has options that do not overlap with the
data model of the Temporal object, toLocaleString() and format() are
supposed to throw a TypeError.
The tests are passing an explicit `hour12` option, which disables any
`hourCycle` option and any `u-hc` Unicode extension. Therefore passing
input locales with `u-hc` is invalid.
```js
let locale = "en-u-hc-h24";
let hcDefault = new Intl.DateTimeFormat(locale, { hour: "numeric" }).resolvedOptions().hourCycle;
assert.sameValue(hcDefault, "h24", "hour-cycle through Unicode extension");
let hc24 = new Intl.DateTimeFormat(locale, { hour: "numeric", hour12: false }).resolvedOptions().hourCycle;
// Incorrect assertion, because |hc24| uses |hour12|, which disables any
// hour-cycle option and the hour-cycle is determined from the locale "en".
// That means |hc24| will be "h23".
assert.sameValue(hc24, hcDefault);
```
Time zone identifiers supported by ICU, but which aren't valid IANA
identifiers.
Implementations not supporting ECMA-402 are theoretically allowed to
support these identifiers, so the tests have to go into the "intl402"
directory.
In https://github.com/tc39/proposal-temporal/pull/2522 which reached
consensus at the March 2023 TC39 meeting, the functionality of
Temporal.ZonedDateTime.p.toLocaleString was changed substantially, to not
directly pass the ZonedDateTime to any Intl.DateTimeFormat methods. This
adds rewrites of all existing tests for toLocaleString, as well as a few
tests to verify that Intl.DateTimeFormat methods no longer support
Temporal.ZonedDateTime arguments.
As we are rewriting the tests anyway, this also ports all of the
Temporal.ZonedDateTime.p.toLocaleString tests that were in staging, to the
correct format for the main tree.
