Everywhere an ISO string is accepted in Temporal, a seconds value of :60
should always be coerced to :59, because of how leap seconds are handled
in ISO strings.
In property bags, a 'seconds: 60' property is not subject to that rule: it
should be handled according to the overflow option if there is one.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
These tests cover, for every API entry point where a Temporal object is
expected, what happens when a value of a different type is passed in that
can't be converted.
Most entry points can convert a string to the expected Temporal type, and
will do ToString on any non-Object argument, and throw RangeError if the
result isn't a string that's convertible to that Temporal type. ToString
will throw TypeError on a Symbol.
Most entry points also take a property bag, and will throw TypeError if
the property bag doesn't have the required properties.
We also have to test for TimeZone and Calendar what happens if the wrong
type is provided as the value of a 'timeZone' or 'calendar' property in
another property bag, up to one level of nested properties.
Adds tests for conversion of a Number whose corresponding toString() value
is a valid ISO string. For some Temporal types this is possible, with a
number like 20220418.
Especially for Temporal.Calendar, we have to take into account the case
where the number is provided as the value for the 'calendar' property in a
property bag, and the case of up to one level of nested property bag as
well.
Regularizes and expands existing tests for this case.
Where possible, observable calls originating from within Temporal, that
require an options argument, should pass `undefined` as that options
argument, rather than `{}` or `Object.create(null)`.
See tc39/proposal-temporal#1685.
These tests check API entry points that convert strings to
Temporal.PlainDate, with a list of various strings that are all not valid
for that context according to ISO 8601.
https://github.com/tc39/proposal-temporal/issues/1753 records the
consensus reached at the October 2021 TC39 meeting to disallow "-000000"
as an extended year, both in Date.parse and Temporal. This adds tests for
the Temporal part of that.
There were two cases where tests in intl402/ had some duplication of tests
that are in built-ins/ as well. Remove this duplication, and restrict the
intl402/ tests to testing things that can't be tested on all hosts.
For cases in the previous commit that actually removed some functionality
from tests in built-ins/, add corresponding tests in intl402/ to preserve
test coverage of that functionality for hosts that do support Intl.
After Intl.NumberFormat v3, default useGrouping is "auto".
We also fix test/intl402/NumberFormat/test-option-useGrouping.js. After v3,
it accepts string and boolean.
We need to set minimumFractionDigits: 1 for the case of {roundingIncrement: 5, maximumFractionDigits: 1} and also adjust the test expectation.
Otherwise, inside testNumberFormat , it will call getPatternParts to format 1.1 and -1.1 and cause pattern mismatch (because the result will be "1" instead of "1.1" in that configuration)
https://github.com/tc39/test262/blob/main/harness/testIntl.js#L2369
The last five lines below are simply WRONG and not according to the spec.
```
const durationFormat = new Intl.DurationFormat();
verifyNotEnumerable(durationFormat, Symbol.toStringTag);
verifyNotWritable(durationFormat, Symbol.toStringTag);
verifyConfigurable(durationFormat, Symbol.toStringTag);
```
Move part of the test of toLocaleString which depends on
15 Amendments to the ECMAScript® 2021 Internationalization API Specification
to intl402. Keep behavior specified in earlier chapters in built-ins
* Add tests for "Intl NumberFormat v3" proposal
This patch is intended to cover only one aspect of the proposal for
ECMA402: the "interpret strings as decimals" feature.
* fixup! Add tests for "Intl NumberFormat v3" proposal
This patch is intended to cover only one aspect of the proposal for
ECMA402: the "grouping enum" feature. It also includes coverage for the
formatting option as already defined by the latest version of ECMA402.
Currently, this test is not conformant to the proposal text.
Temporal.TimeZone.from() calls ToTemporalTimeZone. Since the argument is
a string, we next go to ParseTemporalTimeZone, where on a string such as
`1994-11-05T08:15:30-05:00[UTC]` we would return _result_.[[Name]] (which
would be equal to `UTC`) and discard the UTC offset string.
Unfortunately, in #3304 I made a last-minute mistake when I added the
uncallable value to the assertion message, and neglected to test it;
Symbols can't be converted to strings like that, so these tests would
fail. This fixes the assertion messages.
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).
Specify a descriptive value for the previously-unused third parameter of
the `verifyFormatParts` function in order to disambiguate error
messages.
This patch was generated with the following command:
sed -i 's/\(verifyFormatParts([^,]\+, \)\([^,]\+\))/\1\2, "\2")/g' \
test/intl402/NumberFormat/prototype/formatToParts/signDisplay-currency-*
This reverts commit b690cb67be, reversing
changes made to 50dd431dff. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
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.
Philip Chimento
Ms2ger
Jesse Alama
Frank Tang
Romulo Cintra
Jesse Alama
Romulo Cintra
Frank Yung-Fong Tang
Jesse Alama
Romulo Cintra
Philip Chimento
Yusuke Suzuki
Mike Pennisi
Yusuke Suzuki
Nikhil Singhal
André Bargull
Rick Waldron
rwaldron
Michael Dyck