Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1829
In a previous version of the specification, there was a fallback to the
intrinsic getOffsetNanosecondsFor when it was undefined.
A number of tests for ECMA402 asserted the exact contents of the array
returned by various `resolvedOptions` methods. This conflicted with the
expectation that more options will be introduced by future editions of
the specification.
Update these tests to assert property order more generically in order to
accommodate implementation of future language proposals and more closely
align with similar tests.
Update all `resolvedOptions` tests to produce more meaningful error
messages (including replacing the generic `arrayContains` assertion with
a specific assertion regarding the value of the first array element).
In each case, it's the scalar value associated with the "description" key.
Normally in test262, this is written in either:
- block notation (indicated by '>' or '|'), or
- flow notation, single-line, on the same line as the key.
In the cases addressed by this PR, the value is instead written in:
- (1x) flow notation, *multi*-line, or
- (2x) flow notation, single-line, on the line *after* the key.
These are valid YAML, but they're styles that test262 doesn't otherwise use,
so could conceivably confuse people or harnesses.
This PR changes them to block notation.
Add tests to make sure DateTimeFormat does not call the instanceof
operator and calls OrdinaryHasInstance instead.
Refs: https://github.com/tc39/ecma402/pull/500
intl402/DateTimeFormat/prototype/formatRangeToParts/date-same-returns-single-date.js is using `formatRange` and `format`.
Fix this test to use `formatRangeToParts` and `formatToParts` since it is the intention of this test.
This patch adds additional tests to intl402/DateTimeFormat/prototype/formatRangeToParts/date-same-returns-single-date.js and
intl402/DateTimeFormat/prototype/formatRange/date-same-returns-single-date.js. The new test uses two dates that are practially-equal,
and ensures the implementation uses `format` or `formatToParts` by detecting they are practically-equal.
macOS system ICU is shipping new CLDR, but it has many overrides on the top of it to make the formatted output suitable for the system.
And in timedatestyle-en.js tests, we intentionally override the CLDR data with the different format.
This change modifies the test to accept that alternative output.
macOS system ICU is shipping new CLDR, but it has many overrides on the top of it to make the formatted output suitable for the system.
And in related-year-zh.js tests, we intentionally override the CLDR data with the different format.
This change modifies the test to accept that alternative output.
http://tc39.es/proposal-intl-DateTimeFormat-formatRange/
The spec draft throws TypeError instead of RangeError.
1.4.5 Intl.DateTimeFormat.prototype.formatRange ( startDate , endDate )
...
4. If startDate is undefined or endDate is undefined, throw a TypeError exception.
1.4.6 Intl.DateTimeFormat.prototype.formatRangeToParts ( startDate , endDate )
...
4. If startDate is undefined or endDate is undefined, throw a TypeError exception.
The invalid 'numberingSystem' options test from RelativeTimeFormat covers a few
more cases, so let's reuse it for NumberFormat and DateTimeFormat.
While there, also add tests using non-ASCII inputs.
Fixes#2540
Frank Yung-Fong Tang
Jesse Alama
Philip Chimento
Mike Pennisi
André Bargull
Michael Dyck
Kate Miháliková
Ujjwal Sharma
ExE Boss
Yusuke Suzuki
Felipe Balbontín
Rick Waldron
Yusuke Suzuki
Frank Yung-Fong Tang
Alexey Shvayka
Caio Lima
Ms2ger
Ms2ger