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
* Temporal: Add an overflow test for date addition with maximum year
* Add tests for other cases
* Fix minimum dates
* Add cases for adding/subtracting the negated duration to the opposite end of the allowed years
These tests cover the case where the ZonedDateTime since() or until()
methods are called with either the receiver or the argument being a
ZonedDateTime instance at either the earliest or latest end of the
supported range.
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.
See: tc39/proposal-temporal#3121
A type assertion in the spec was incorrect, but the assertion wasn't hit
in the Firefox implementation in any test262 test. These three tests add
coverage for all the paths that would have hit that assertion.
Changes made to:
- PlainDate
- PlainYearMonth
- ZonedDateTime
- PlainDateTime
- PlainMonthDay
Merged calendar-number.js and calendar-wrong-type.js, due to no special behaviour of number to be tested.
Extracted string tests to calendar-iso-string.js and renamed the file to calendar-invalid-iso-string.js, due to the contents of the file initially testing invalid ISO strings.
Closes#3873
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.
These tests did not fully cover Temporal.Duration.prototype.round and
Temporal.Duration.prototype.total because they called those methods on a
blank duration (all components zero), for which there is an early return
in round() and total().
This meant that we missed an assertion that would be hit after the early
return.
This makes sure to test both blank and non-blank Durations with these
relativeTo strings, and expect some strings to fail at different steps
with the two cases.
See: tc39/proposal-temporal#3015
