These (from #4619 and #4625) are very similar and I'm also going to add
more cases to them in the next commit.
Also add similar tests to Instant and PlainTime.
The spec describes the internal representation of Duration as float64-
representable integers. There are a few tricky ways that it is
observable if an implementation does not do this correctly. Here are
some tests for them.
These tests confirm that Temporal-object-like property bags have the
correct default values for their optional properties.
This provides coverage for a V8 bug:
https://issues.chromium.org/issues/446728405
These tests cover the normative change approved in the July 2025 TC39
plenary. See https://github.com/tc39/proposal-temporal/pull/3130.
All properties of user-passed options objects should be read and cast
before any "algorithmic validation" is done.
This is a lot of tests, that cover every entry point where an options
object is passed in, where subsequently an exception can be thrown or user
code can be called.
However, the normative change only affects 10 of these tests:
- Instant.p.since,until,toString
- PlainDate.p.since,until
- PlainTime.p.since,until
- PlainYearMonth.p.since,until
- ZonedDateTime.p.toString
The other 35 tests simply close a gap in coverage.
Remove the existing "instant-string-limits.js" that only applied to APIs
where ToTemporalInstant was called. Add "argument-string-limits.js" tests
everywhere ISO strings are converted.
Related to tc39/proposal-temporal#2985
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.
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.
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.
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.
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.
Adds tests that verify that Instant strings cannot include offset time
zone annotations with sub-minute units.
Also removes a few staging test cases that, due to a polyfill bug, were
incorrectly passing.
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.
I noticed a small test hole in codecov: we weren't testing
Temporal.Instant parsing with trailing zeroes in the offset.
I also didn't see fractional offset testing, so added that too.
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.
As per IETF review, an IXDTF string (ISO 8601 with annotations) is no
longer valid if it contains more than one u-ca annotation and at least one
of the annotations is marked critical.
Removes tests where such a string was assumed to be valid, and adds new
ones with a few variations on invalid strings.
Previously, "nested" calendar property bags were unwrapped up to one
level. That is, this object:
{
calendar: {
// ...Temporal.Calendar methods
}
}
would not be considered to implement the Calendar protocol, but would have
its calendar property used instead, if it were passed to an API that
required a Calendar 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
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
