Reorganize the PlainDate.p.add tests by topic ("basic arithmetic", "leap
years") to make them easier to adapt for non-ISO calendars. A third
topic would be "constraining days" but it turns out that is barely
tested!
This adds tests for overflow constrain/reject with years, expands the
coverage with months to test edge cases using 12, 13, 24, and 25 months,
and cleans up a bit.
I started to add weeks and days tests for this in the previous PR, but
on reflection I don't think those are that useful.
This adds tests for overflow constrain/reject with years, expands the
coverage with months to test edge cases using 12, 13, 24, and 25 months,
and cleans up a bit.
Note the tests adding a number of years to get from a leap month in one
year to the same leap month in another year! 2012 has M04L in the
Chinese calendar and M03L in the Dangi calendar, so these are different
between the two calendars.
Tests how Intl.DateTimeFormat formats eras in various calendars. The
actual output is implementation-defined, but we can test a few things:
- Calendars with multiple eras have distinct values for the era part
when formatting dates in each era.
- Calendars with one era have the same value for the era part when
formatting dates with positive and negative era years.
- Calendars without eras do not include an era part in the format.
Some calendars are missing from this test because their era
configurations were updated in CLDR 48. I will add those in a separate
PR which can be merged when implementations have had more time to update
to that version of CLDR.
Co-Authored-By: Philip Chimento <pchimento@igalia.com>
This test calls Intl.DateTimeFormat.prototype.formatToParts() and
format() on dates in lunisolar calendars in leap and non-leap months.
The actual output is implementation-defined so there isn't much specific
that we can test here.
Co-Authored-By: Philip Chimento <pchimento@igalia.com>
Tests the Intl.DateTimeFormat.prototype.resolvedOptions().calendar value
for each supported calendar.
Co-Authored-By: Philip Chimento <pchimento@igalia.com>
CLDR 48 changed the era name, so the output is now `"10/11/-79 Śaka"`.
This leads to taking the `vulnerableToBceBug == true` code path, which
then fails because no `RangeError` is thrown. Rather than adding the new
output, simply remove the lines to handle old nodejs versions.
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.
