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
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.
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
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.
For each Temporal type, add a test (which should not be sensitive to the
exact locale format) that ensures dateStyle affects the output, for a
Gregorian and non-Gregorian calendar.
See https://github.com/tc39/proposal-temporal/issues/2058
In https://github.com/tc39/proposal-temporal/pull/2522 which reached
consensus at the March 2023 TC39 meeting, the functionality of
Temporal.ZonedDateTime.p.toLocaleString was changed substantially, to not
directly pass the ZonedDateTime to any Intl.DateTimeFormat methods. This
adds rewrites of all existing tests for toLocaleString, as well as a few
tests to verify that Intl.DateTimeFormat methods no longer support
Temporal.ZonedDateTime arguments.
As we are rewriting the tests anyway, this also ports all of the
Temporal.ZonedDateTime.p.toLocaleString tests that were in staging, to the
correct format for the main tree.
Previously, "nested" time zone property bags were unwrapped up to one
level. That is, this object:
{
timeZone: {
// ...Temporal.TimeZone methods
}
}
would not be considered to implement the TimeZone protocol, but would have
its timeZone property used instead, if it were passed to an API that
required a TimeZone protocol object.
These nested property bags are no longer supported. Discussion:
https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753
Corresponding normative PR:
https://github.com/tc39/proposal-temporal/pull/2485
This is the replacement of the old API with the new API, .timeZoneId and
.getTimeZone(). Semantics will be corrected in the following commit.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
In these tests, we should make a distinction in the name for clarity. It's
testing a time zone passed as a property in a property bag (either as an
argument, or as a relativeTo option), so name it accordingly as we do with
other tests in the same folder.
This tests the normative change from
https://github.com/tc39/proposal-temporal/pull/2260
which achieved consensus in the July 2022 TC39 meeting.
The return value from a userland getOffsetNanosecondsFor method is no
longer allowed to be exactly one 24-hour day.
For cases in the previous commit that actually removed some functionality
from tests in built-ins/, add corresponding tests in intl402/ to preserve
test coverage of that functionality for hosts that do support Intl.
