Without custom calendars and time zones there are actually a bunch of
things that we now can't test on implementations that don't have non-ISO
calendars or non-UTC time zones. (Alternatively, we can say that these are
functionalities that those implementations don't have to implement.)
These are no longer possible without custom objects. Also add an exception
for calendar and timeZone properties in property bag observers so they are
not treated as objects.
Many tests tested some functionality while asserting that there were no
calls of calendar or time zone methods. We can continue testing the
functionality, but there are no more methods to call, so we can delete
those parts of the tests.
It's no longer possible to fake built-in time zones using custom objects.
So testing DST shifts will have to use real built-in time zones. Replace
TemporalHelpers.springForwardFallBackTimeZone with America/Vancouver (it
was modelled on the DST transitions in 2000) and
TemporalHelpers.crossDateLineTimeZone with Pacific/Apia (it was modelled
on the 2011 switch to the other side of the international date line.)
These tests have to move to the intl402/ folder since non-Intl-aware
implementations are allowed (but not required) to support any built-in
time zones other than UTC.
In many cases we created a TimeZone or Calendar instance from a built-in
time zone or calendar. These tests can be trivially adapted to just use
the string ID.
Temporarily replace them with getISOFields().calendar/timeZone just to
keep the tests running until we remove Calendar and TimeZone objects
altogether.
See: tc39/proposal-temporal#2826
Following the upstream ECMA-402 change tested in the previous commit, add
test coverage for the corresponding functionality in Temporal. Fix one
test that was erroneous.
This should produce all the same results (except for a change to weeks
balancing in round(), which is now more consistent with since()/until())
but leads to different observable user code calls.
See https://github.com/tc39/proposal-temporal/issues/2742
These tests were supposed to test an invalid ISO string being used as the
`calendar` property in a property bag. Instead they were testing being
used as an invalid ISO string directly where a PlainDate input was needed.
(That is also already covered elsewhere.)
Due to overlooked copy-paste errors we were creating the wrong type of
instance in these tests, and therefore testing the wrong method.
(Add blank line for consistency with the other instances of these tests.)
With test cases kindly provided by Anba, this adds test coverage for the
abrupt completion in the last step of DifferenceTemporalPlainDateTime,
where the resulting Duration components have mixed signs.
See: https://github.com/tc39/proposal-temporal/issues/2783
As per IETF, annotation keys may only consist of lowercase letters,
dashes, and digits, and an optional leading underscore. Uppercase letters
are non-syntactical. Add tests covering this.
This adds tests specifically for every kind of case that changes due to
the tweak to the date difference algorithm: differences from a longer
month to a shorter month, when the months are adjacent, in the same year
but not adjacent, and in different years.
Also adds tests for a case that does *not* change, but would trip on an
incorrectly implemented algorithm: when the intermediate months value
falls at the end of February.
There was incidental coverage of the change to the date difference
algorithm in other tests. Those are adjusted, as well.
Normative change: https://github.com/tc39/proposal-temporal/pull/2759
Consensus in February 2024
Adapts the tests that checked arbitrarily long loops, to now check that an
exception is thrown if the loop would happen.
Adds tests that exercise the newly added checks on return values of
getPossibleInstantsFor and getOffsetNanosecondsFor that limit UTC offset
shifts to 24 hours or less.
Also updates some step numbers in related tests.
Adapts or removes tests that relied on creating durations that are now out
of range. Adds new tests for maximum in-range and minimum out-of-range
durations.
A few results change because the algorithm previously used for rounding
didn't always add duration units to dates in RFC 5545 order, and we also
introduce a special case for rounding with largestUnit years or months and
smallestUnit weeks.
In order to fixtc39/proposal-temporal#2563, we added invocations of
BalanceDurationRelative after some invocations of RoundDuration. These
cause observable calendar calls, which must be accounted for in some
existing tests.
See https://github.com/tc39/proposal-temporal/issues/2563
The old behaviour was encoded in one test in staging, but the behaviour of
largestUnit in duration rounding has changed since that test was written.
Therefore I'm assuming that toString() should've been updated when that
happened.
In the AO DisambiguatePossibleInstants, a PlainDateTime instance is passed
to user code. This instance should have the built-in ISO 8601 calendar.
Here are some tests that ensure it does.
See tc39/proposal-temporal#2671.
This removes several loopholes where it was possible to return particular
values from user calls that would cause infinite loops, or calculate
zero-length days.
Note the monkeypatch of getPossibleInstantsFor in test/built-ins/Temporal/
TimeZone/prototype/getInstantFor/argument-builtin-calendar-no-array-
iteration.js.
Other than that, all the tests are basically identical.
Philip Chimento
Adam Shaw
Aditi