Now that we don't have to deal with strings or objects as input to the
calendar ID or time zone ID parameter of constructors, we accept only the
data that actually goes into the internal slots.
Previously getISOFields() was used to get the exact value of the
[[Calendar]] and [[TimeZone]] internal slots, as well as to get the
reference ISO year for PlainMonthDay and reference ISO day for
PlainYearMonth.
Use calendarId and timeZoneId for the former and toString() for the
latter.
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.
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.)
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.
This commit verifies that ISO strings with sub-minute offsets cannot
be parsed into time zone identifiers. This was a change introduced in
the recently-merged tc39/proposal-temporal#2607, but tests for this case
were missing from #3862 (the tests for that PR).
I noticed in codecov results on an unrelated PR that this case wasn't
being tested, so fixing that mistake now.
Codecov showed that PlainTime strings like "09:00:00Z[UTC]" or
"09:00:00Z" were not being tested. This commit fills that gap.
It'd probably be good to make similar changes for other Plain* types,
but Codecov didn't complain about them so they may be covered
via other tests so it was less urgent.
Edits Temporal tests to account for changes in
https://github.com/tc39/proposal-temporal/pull/2574.
This PR stops coercing non-string primitive inputs to strings
in Temporal methods, to avoid cases where numbers
are coerced to syntactically valid but often unexpected
string results.
Philip Chimento
Aditi
Justin Grant