Support for non-IANA time zones should be prohibited even in non-Intl implementations

[gibson042]

cf. #2171 (comment)

I think some kind of normative change should be pursued—it makes me uncomfortable that behavior valid in an ECMA-262 implementation is disallowed by ECMA-402, making adoption of ECMA-402 a backwards-incompatible change for at least a hypothetical set of implementations. It seems to go against the spirit of ECMA-402 (which is generally quite liberal regarding implementation-defined behavior), and I'm not aware of any other aspect that is so constrained. Is there a ticket to bring them into accord, either by relaxing ECMA-402 or tightening ECMA-262?

ECMA-402 currently prohibits implementations from supporting non-IANA time zones. To uphold the invariant that adding ECMA-402 support to any ECMA-262 implementation should not introduce breaking changes, ECMA-262 should impose the same constraint.

Analogous behavior for calendars with respect to CLDR is being proposed in #2193.

Alternatively (but less preferably in my opinion), ECMA-402 could be relaxed to allow support for non-IANA time zones.

[gibson042]

See also #1996.

[ptomato]

I wonder if this should be solved in ECMA-262 before we make any according change in Temporal. According to the definition of LocalTZA (which I am hoping to replace in tc39/ecma262#2781, though this question remains open) it's currently spec-compliant (though not recommended) for an implementation to base its return value of LocalTZA on a non-IANA time zone. For example, even leaving Temporal out of consideration, there is currently nothing preventing this:

> d = new Date()
> d.toISOString()
// '2022-05-23T20:43:39.550Z'
> d.toString()
// 'Mon May 23 2022 13:20:39 GMT-0723 (Pacific Bizarro Time)'

The time zone's description string is always implementation-defined and has nothing to do with the IANA database, but the offset (-07:23) is not the current offset of any IANA time zone.

[gibson042]

Agreed. I think this can be addressed in ECMA-262 ahead of Temporal, but I don't think it can wait until after Temporal because so much new behavior is observable (in particular, probing for whether or not a particular time zone name is supported).

[gibson042]

We have no desire to constrain ECMA-262 in this way, but rather to update ECMA-402 to accommodate its liberal range of conforming behavior: tc39/ecma402#683