Expands and updates (following the normative change in
https://github.com/tc39/proposal-temporal/pull/3107, approved May 2025)
the current coverage with cases where the number of seconds is
incorrect, or rounded.
Adds missing coverage for sub-minute offsets in strings passed to
Temporal.ZonedDateTime.compare.
Adds the unusual test case of Pacific/Niue on October 15, 1952, where
the offset shifted by 20 seconds to a whole-minute boundary.
Fixes a few minor errors in the existing tests such as a missing ] in a
string, and the wrong sign for the offset in Africa/Monrovia in property
bags.
getTimeZoneTransition return values should always correspond with UTC
offset transitions, not with time zone metadata changes such as making
DST permanent or updating abbreviation strings.
See: https://github.com/tc39/proposal-temporal/issues/3105
Check that implementations correctly detect time zone transitions that
are close together. Additionally, test startOfDay() since the time zone
transitions in Brazil occur at midnight.
See https://github.com/tc39/proposal-temporal/issues/3110
If you have a leap day, such as February 29, and you get input such as
{ monthCode: "M02", day: 30 }, { overflow: "constrain" }, then you want
the day to be constrained to the leap day February 29, not February 28
as the maximum day would be in a common year. Add tests for this case
for each supported calendar.
Add coverage in particular for dateStyle: undefined and timeStyle:
undefined, and for dateStyle applying to PlainMonthDay/PlainYearMonth
which were not tested.
As of the Time Zone Canonicalization proposal which is stage 3, the
original time zone name should be preserved in Intl.DateTimeFormat
.prototype.resolvedOptions.
Add a separate test that uses Temporal.ZonedDateTime.prototype.equals
to test the canonicalization behaviour.
"islamic" is underspecified because it doesn't include any information
which location and algorithms should be used to approximate new moon
observations. Instead switch to "islamic-tbla".
The test for https://github.com/tc39/ecma402/pull/724 (added in
https://github.com/tc39/test262/pull/4328) didn't take the Time Zone
Canonicalization proposal into account; but it should, because that
proposal is stage 3.
As of that proposal, the [[TimeZone]] slot of DateTimeFormat gets the
case-regularized original identifier, no longer the primary identifier. So
the resolvedOptions().timeZone property also no longer returns the primary
identifier.
Adds a test for each Temporal object's toLocaleString() method, formatting
them with only one option e.g. { year: 'numeric' } and comparing it with
the corresponding output for legacy Date.
See tc39/proposal-temporal#2796.
These tests add coverage for a corner case in the TZDB. In spring 1919,
the America/Toronto time zone switched to DST at 23:30 on March 30th,
skipping an hour ahead to 00:30 on March 31st. This meant that both March
30th and March 31st were 23.5-hour days.
See: https://github.com/tc39/proposal-temporal/issues/2910
Tweak some tests to provide coverage of new execution paths in the spec,
such as calling GetOptionsObject inside ToTemporal___; add a few new tests
for things that weren't covered before, such as rounding a PlainDateTime
at the edge of the range; and tweak the tests verifying when the
properties of the options bag are read, which I made a mistake in #4119.
See: https://github.com/tc39/proposal-temporal/pull/2925
Temporal doesn't specify concrete era names, so tests shouldn't assert
for example that the era code of the current Gregorian era is `"ce"`. We
still want to validate the era names somehow however, so allow alternative
era names using the era codes from the "Intl era and monthCode" proposal.
As in the previous commit, without custom calendars and time zones, some
functionality cannot be tested on implementations that don't have any
other calendars and time zones than iso8601 and UTC.
Some of the staging tests fall in this category. We take the opportunity
to port these into proper tests, in the intl402/ folder.
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.)
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.
Some of the tests can be removed altogether since they deal with what
forms of input can be passed to ToTemporalTimeZoneSlotValue. Those are
tested on every method that takes a TimeZone as input.
Other tests are still relevant, but need to move to ZonedDateTime.p.equals
where the various quirks of time zone equality can still be tested. (Some
of these still will be removed in a following commit because they use
time zone objects.)
See: #2826
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.
See tc39/proposal-temporal#2825. This is a mass removal of tests that use
this functionality, in a separate commit for ease of review. Further
adjustments will be made in the following commit.