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
Frank Tang
Philip Chimento
Ms2ger
Romulo Cintra
Jesse Alama
Romulo Cintra
Frank Yung-Fong Tang
Jesse Alama
Jesse Alama
Romulo Cintra
Philip Chimento
Yusuke Suzuki
Mike Pennisi
Yusuke Suzuki