This takes the current 'until-across-lunisolar-leap-months.js' which
didn't test much of anything too carefully, and expands it to cover
comprehensive date difference arithmetic across and including leap
months in the Chinese and Dangi calendars, for PlainDate, PlainDateTime,
and ZonedDateTime.
Hebrew calendar arithmetic will follow in a different PR.
Similar to #4652 - note that the expected results are different for the
cases labeled "exhibits calendar-specific constraining"! Covers date
difference arithmetic across and including leap months in the Hebrew
calendar, for PlainDate, PlainDateTime, and ZonedDateTime.
This reverts commit d124e1486c007a737411ea7110458e93680b7953 (#4309).
The Intl Era Monthcode proposal precludes this alternative era for the
Chinese calendar, so implementations that have it should not pass the
test.
Japanese eras can begin in the middle of a month. This adds tests for
the existing behavior, which is that PlainYearMonth.from returns
a PlainYearMonth with an era matching the first day of the month,
even when that conflicts with the era given by the argument.
See https://github.com/tc39/proposal-temporal/issues/3150 for more details.
* Add remaining tests specific to await-using statement syntax
* PR feedback and minor fixes due to banning 'await using' in switch case/default
* Additional updates
* Fix comment formatting
* Fix esid
* Fix test implementation
* Fix error type in test
* Add remaining tests specific to using statement syntax
* Fix incorrect test, esid
* Add 'for(using of=' test
* PR feedback and minor fixes due to banning 'using' in switch case/default
* Fix spacing around esid
* Fix test implementation
* Fix error type in test
V8 is discarding these tests (which were stale and have not been run for
quite a while) and instead relying on test262 for coverage. I converted
them to test262 format, deleted ones that no longer applied, and removed
Calendar and TimeZone objects from them.
They can live in staging until we figure out whether there's anything
here that isn't already covered in the main tree.
See https://chromium-review.googlesource.com/c/v8/v8/+/7100673
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
