ICU calendars - how to handle {constrain, reject} for out-of-range {eraYear, era} value pairs?

[cjtenny]

Context: tc39/proposal-temporal#1245 (comment)

How should the ICU calendars handle values of eraYear and era that are "out-of-bounds". For example, if an era lasts ten years, does eraYear: 15 mean 5 years into the next era? For the gregorian calendar, does {era: 'ce', eraYear: 0} mean 1 BCE?

This does not affect the ISO calendar, which does not support eras, and therefore will not lead to any changes in the stage3 "frozen" spec text. It does, at the moment, affect the polyfill.

cc @Manishearth, @justingrant

[ptomato]

IMO it should always adjust the era accordingly. Suppose you have PlainDate.from({ era: 'reiwa', eraYear: 100, month: 1, day: 1, calendar: 'japanese' }) and the Emperor decides to retire sometime within the next 98 years. You don't want that code to either suddenly start throwing (reject) or suddenly start returning a different date than before (constrain).

[justingrant]

IMO it should always adjust the era accordingly.

FWIW, the polyfill currently works this way.

[Manishearth]

This makes sense, though I think we should document this behavior in case folks are using the reject mode as a "strongly validate inputs" mode (if folks want this behavior they can just compare the before/after eras)

[Louis-Aime]

I agree with you all.
This is the way the original era concept is generally understood.
Strictly speaking, it is a sort of balance option.

[ptomato]

Let's move this to the ecma402 issue tracker.