The options-invalid.js tests were also covered by options-wrong-type.js.
The tests for add/subtract without an options argument were also covered by options-undefined.js.
ISO strings may separate the time from the date with a case-insensitive T,
or a space. This adds tests to all entry points that take ISO strings, to
ensure that they accept an uppercase T, lowercase T, or space as the time
separator.
These tests are based on the one test for Temporal.PlainDateTime.from that
was already present.
I suggested in #3517 that these lines should be removed but didn't realize
they must be present because TemporalHelpers.assertPlainDateTime is going
to check the 'era' and 'eraYear' properties.
This adds coverage for the situation where we get a different answer from
Temporal.Duration.compare depending on whether relativeTo resolves to a
PlainDate or ZonedDateTime.
See discussion in
https://github.com/tc39/test262/pull/3505#discussion_r859994610
Some of these strings wouldn't have been valid even with a valid year in
them (e.g. strings ending in +01:00[UTC]) so fix up the strings that we
test. While touching these tests, I took the opportunity to regularize
them, and add some missing ones for ISO strings that convert to Calendar
and TimeZone.
Be consistent about creating Temporal objects for use in tests with direct
constructor calls, instead of relying on string coercions. This reduces
coupling in the tests.
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.
Each from() method except Calendar and TimeZone should test that when you
pass an instance of that type, the return value is a clone of that
instance, and a distinct object.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
In order to test the referenceISODay of a PlainYearMonth we add an
argument to TemporalHelpers.assertPlainYearMonth.
In Date.parse() and new Date(), representations of the year 0 as -000000
must not be accepted. In the case of Date.parse(), they should yield NaN,
and in the case of new Date(), they should yield an invalid Date object,
whose valueOf() is NaN.
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.
The test for a TimeZone created from an ISO string with multiple offsets
was missing from the Temporal.ZonedDateTime constructor, whereas it was
present for several other APIs. Add it.
We already had similar tests to these for other methods, such as
Temporal.PlainTime.prototype.equals(). since() and until() should have
these tests too.
Update assertion messages in all of the existing tests as well, as per
Ms2ger's review comment.
An object may be given in any context where a Temporal.Instant is expected
(see ToTemporalInstant). There is no conversion from a property bag to an
Instant, unlike with other Temporal types. Instead the object is converted
to a string, and if its toString() method yields a valid ISO string, the
conversion succeeds. (An object with the default Object.prototype.toString
will not.)
