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.
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.
This consolidates the few existing tests for options bags in Temporal
being of the wrong type, and adds them for every entry point in Temporal
that accepts an options bag.
These are mostly identical tests, but there is a variation for methods
like round() where either an options bag or string is accepted.
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.
https://github.com/tc39/proposal-temporal/pull/1907 was a bug that caused
negative Duration strings with fractional units to be rounded incorrectly.
Add tests that ensure the rounding mode is correct.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
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.
https://github.com/tc39/proposal-temporal/pull/1780 fixed a typo in the
UnbalanceDurationRelative abstract operation, which should affect the
entry points tested here.
This was a normative change that achieved consensus at the October 2021
TC39 meeting.
This requires a few adjustments of time zone names and offsets in some
places. The only named time zone that is required to be supported by an
implementation not supporting ECMA-402 is "UTC".
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1873
This adds a new Temporal helper calendar that asserts that its dateAdd()
method is always called with a PlainDate instance. This allows testing
that relativeTo parameters are always converted to PlainDate if they are
not ZonedDateTime and not undefined. Prior to the normative PR, they
would be converted to PlainDateTime instead.
Additionally and optionally, the helper calendar can also assert that its
dateAdd() method is called with a specific PlainDate instance. This allows
testing that the instance is the same PlainDate passed as the relativeTo
parameter (in the case of Duration methods) or is the receiver (in the
case of PlainDate methods). For the PlainDateTime and PlainYearMonth
methods the PlainDate instance is synthesized internally so there is no
need to assert that dateAdd() is called with a specific instance.
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.
