There was one remaining Temporal test that was parsing an ISO string
with a sub-minute offset into a Temporal.TimeZone. A polyfill bug was
allowing this test case to pass, even though after
tc39/proposal-temporal#2607 it should have failed.
This commit removes the bad test case.
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.
These tests accompany a Temporal PR that works around a bug in
ICU 73.1 (which ships with Node 20). These test changes enable
tests to pass in both the buggy state and after the bug is eventually
fixed.
I wrote a similar test for Temporal.ZonedDateTime.p.toLocaleString, so
while this was fresh I decided to do the same for the other toLocaleString
calendar mismatch tests that were in staging.
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.
Compare semantics for custom time zones that _don't_ extend
Temporal.TimeZone (and therefore don't have the internal slot) use the
value of the .id property, instead of calling toString().
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
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
Compare semantics for custom calendars that _don't_ extend
Temporal.Calendar (and therefore don't have the internal slot) use the
value of the .id property, instead of calling toString().
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
In several tests involving custom calendars, we need to change the
implementation of dateFromFields/monthDayFromFields/yearMonthFromFields so
that the returned object gets the receiver as its calendar after chaining
up to the builtin implementation.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
Tests for the process of calculating the reference ISO day for
Temporal.PlainYearMonth and the reference ISO year for
Temporal.PlainMonthDay.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2475
In https://github.com/tc39/proposal-temporal/pull/2474, which achieved
consensus at the TC39 plenary meeting of 2023-01-31, the implementation-
defined steps for Temporal.Calendar.prototype.mergeFields had their
language tightened, to better specify what implementations must do.
This adds tests covering the new spec language, and moves one related test
out of staging.
Previously in a few cases (calendar units in Duration) the value for the
roundingIncrement option had no upper limit, other than having to be
finite. These tests cover a normative change limiting it to 1e9.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2480
Adapt to the following changes in CLDR 42 in Node 19:
- Some spaces in formats replaced by other whitespace unicode characters
- German format changes, which may be bugs (see
https://unicode-org.atlassian.net/browse/CLDR-16243)
This commit makes affected tests more resilient to Intl.DTF output
changes between Node versions.
A good idea for a future PR would be to change these tests to rely less
on CLDR formats while still testing that Temporal and Intl are behaving
as expected.
As per the discussion in
https://github.com/tc39/proposal-temporal/issues/2379#issuecomment-1248557100
and the PR https://github.com/tc39/proposal-temporal/pull/2398, which is
to be presented for consensus to TC39 in the upcoming plenary meeting, UTC
offsets and the Z designator should be disallowed after any date-only
strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to
follow a time component. Z remains disallowed in any string being parsed
into a Plain type.
Annotations become allowed after any ISO string, even YYYY-MM and MM-DD
where they were previously disallowed.
Based on the improvements just made to the calendarName option, improve
the tests for the timeZoneName option of ZonedDateTime.prototype.toString
as well.
Since we are going to be adding a new test for calendarName: "critical",
take the existing tests for various values of the calendarName option, and
regularize them. Previously, depending on which type's toString() method
was under test, the tests had various degrees of thoroughness, and some
were only present in staging.
Several tests in staging use the Pacific/Apia IANA time zone to test the
behaviour of various algorithms for the case where Samoa skipped the
entire day of Dec. 30, 2011, when they switched from one side of the
International Date Line to the other. Since implementations are not
technically required to support IANA time zones, add a fake Samoa time
zone to TemporalHelpers that has the same transition, and use it in those
tests.
(The time zone isn't exactly the same as Pacific/Apia, since Samoa also
observes DST and this time zone doesn't. It's only the same for this one
transition.)
See: #3649
Some tests in staging used various IANA time zones in order to test DST
behaviour. Since implementations are technically not required to
understand IANA time zones, we have a fake DST time zone in
TemporalHelpers. Use that instead.
For a few cases where it's not practical to use the fake DST time zone
(because it only has one spring-forward and one fall-back transition, for
example), move a few tests into staging/Intl402/Temporal/.
See: #3649
As much as possible, remove non-ISO calendars and IANA time zones from the
Temporal tests in the staging folder.
In most cases, the non-ISO calendar can be replaced with the ISO calendar.
In other cases, create a custom calendar object with the appropriate
return value from toString(), and any other methods needed for that
particular test.
For time zones, in most cases the time zone can be replaced with UTC or a
constant offset time zone. Sometimes a custom time zone object with the
appropriate toString() is sufficient.
Move timezone-america-la.js to staging/Intl402/Temporal/ since its whole
point is to test an IANA time zone. Create a new tzdb-transitions.js in
staging/Intl402/Temporal to test behaviour of Temporal.TimeZone's
getPreviousTransition and getNextTransition for IANA time zones, since
UTC and constant offset time zones always return null for these methods.
There are still some cases where specific DST behaviour is tested. These
will be addressed in following commits.
See: #3649
Take all the existing tests for round() calculations using different
rounding modes and standardize them. Add tests for Duration, Instant and
ZonedDateTime, which were still in the old format in staging.
Take all the existing tests for since/until calculations using different
rounding modes and standardize them. Add tests for Instant and
ZonedDateTime, which were still in the old format in staging.
The doAsserts is not correct for case like "P100000000000000000000000000Y"
If we test "P100000000000000000000000000Y" because the filed in Duration is only required to
"A float64-representable integer is an integer that is exactly representable as a Number value. That is, for a float64-representable integer x, it must hold that ℝ(𝔽(x)) = x." per
https://tc39.es/proposal-temporal/#sec-properties-of-temporal-duration-instances
The duration it hold may produce string such as
"P99999999999999987584860160Y"
even the test only test the first 10 digits ( log(10^10)/log(2) = 33 bits)
Change the test to test
"P100000000000001000000000000Y" instead, so a negative numerical error will not change the start of the string
from "P1000000000" to "P9999999999"
"15Z" will throw RangeError because Z match
UTCDesignator =>
TimeZoneUTCOffset =>
TimeZoneUTCOffset TimeZoneBracketedAnnotationopt =>
TimeZoneopt
and "15" match
1 DecimalDigit =>
Hour =>
TimeHour =>
TimeSpec
so "15Z" match
TimeSpec TimeZoneopt =>
TimeSpecWithOptionalTimeZoneNotAmbiguous =>
TimeSpecWithOptionalTimeZoneNotAmbiguous Calendaropt =>
CalendarTime =>
TemporalTimeString
Therefore
13.37 ParseTemporalTimeString ( isoString )
https://tc39.es/proposal-temporal/#sec-temporal-parsetemporaltimestring
will succeess in 2. If parseResult is a List of errors, throw a RangeError exception.
but the in step 3
3. If parseResult contains a UTCDesignator Parse Node, throw a RangeError exception.
the "Z" is UTCDesignator so it will throw RangeError.
Due to the TZDB's recent merging of time zones whose pre-1970 data was
different but post-1970 have been the same, this test is going to start
failing on implementations with up-to-date time zone data (because the
Europe/Amsterdam time zone was absorbed into Europe/Brussels in the latest
update.)
It's on our to-do list to remove all dependencies on IANA time zones from
the Temporal tests in staging/,
(see https://github.com/tc39/test262/issues/3649#issuecomment-1232326175)
but this one is more urgent.
Now that we have a staging directory, we can add the old-style tests from
proposal-temporal and avoid having to sync PRs across two repositories
when we convert them to test262 style.
Ms2ger wrote a script to convert them to be executable with the test262
harness, and this is the result of running that script on the remaining
Temporal.Instant tests in proposal-temporal.
More tests of other Temporal types to follow.
Justin Grant
Philip Chimento
Shu-yu Guo
José Julián Espina
Aditi
Frank Yung-Fong Tang
Philip Chimento
Ms2ger