Coverage gap: Incorrect behaviour at end of range for Chinese calendar

[ptomato]

Spotted by @Josh-Cena

const d = Temporal.PlainDate.from("+275760-09-13").withCalendar("chinese");
d.year; // RangeError
d.toPlainYearMonth(); // RangeError

This behaviour is not allowed by the spec. Any valid PlainDate must have a valid year property. The toPlainYearMonth method might throw at the beginning of the range if the first of the calendar month is outside the ISOPlainYearMonth range, but I believe that can't happen at the end of the range.

This behaviour isn't covered by test262. Firefox apparently has this bug.

[Josh-Cena]

btw this happens for the other end too. A year that's too negative also throws.

It looks like this happens for chinese, dangi, islamic, islamic-rgsa, and islamic-umalqura, but not other calendars, but weirdly not for others including hebrew which I thought should be quite similar.

[anba]

This behaviour isn't covered by test262. Firefox apparently has this bug.

It's not a bug per-se, but instead an additional restriction, because the ICU4X implementation doesn't yet handle large dates for some calendars. As soon as ICU4X is fixed, we can remove these limitation:

• https://searchfox.org/mozilla-central/rev/c5432a86ece2ce8671e7aefbe43fed9a10151227/js/src/builtin/temporal/Calendar.cpp#627-630,636-639
• https://searchfox.org/mozilla-central/rev/c5432a86ece2ce8671e7aefbe43fed9a10151227/js/src/builtin/temporal/Calendar.cpp#667-670,676-679

ICU4X issue: unicode-org/icu4x#4917

[anba]

[...] not for others including hebrew which I thought should be quite similar.

The hebrew calendar doesn't have this restriction, because it uses plain math for its calculations: https://en.wikipedia.org/wiki/Hebrew_calendar#Calculations

[ptomato]

This is covered by test262 now, so I'll remove that label. I have looked at whether we want to try to work around that restriction in the polyfill, but won't have time to implement it in the near future.