Should built-in calendars of non-Intl implementations be limited to "iso8601"?

[gibson042]

It seems strange to me that an ECMA-262 implementation is prohibited from supporting e.g. "gregory" or "islamicc" calendars unless it also implements all requirements of ECMA-402, but that is the current state of https://tc39.es/proposal-temporal/#sec-temporal-isbuiltincalendar .

[ljharb]

I'm pretty sure Intl shouldn't have any powers that hosts don't have.

[ptomato]

In the other thread you mentioned that toLocaleString is an extension point, which I had forgotten about. Although I really don't think it's a good idea to add more implementation-defined behaviour to ECMA-262, I can understand this point of view.

I think we could solve this by adding language to these operations that approximately says "this is the minimal implementation for hosts that don't include ECMA-402", like we do for time zones.

The complication that I'd like to avoid is having a similar situation as #1996 but for calendars instead of time zones. I think we can avoid this by forbidding implementations from supporting non-UTS-35 calendars, and saying that any UTS-35 calendars that they do support must be subject to the same specifications as described in ECMA-402.

[gibson042]

I think we could solve this by adding language to these operations that approximately says "this is the minimal implementation for hosts that don't include ECMA-402", like we do for time zones.

The complication that I'd like to avoid is having a similar situation as #1996 but for calendars instead of time zones. I think we can avoid this by forbidding implementations from supporting non-UTS-35 calendars, and saying that any UTS-35 calendars that they do support must be subject to the same specifications as described in ECMA-402.

Right, my suggestion at #2155 (comment) was

This function returns a List of String values representing calendar types supported by the implementation. The contents of the List are implementation-defined, but must contain *"iso8601"* and must not contain any String value that does not identify a calendar type in the Unicode Common Locale Data Repository (CLDR).

[ptomato]

We have a spec PR to consider, #2193

I wouldn't be opposed to this, although do we have any implementations that are likely to be in this in-between space?