#2482 made DefaultTimeZone's result is now observable (matters for offset strings)

[justingrant]

When we introduced Temporal.Now.timeZoneId() as part of the implementer-requested string slots change in #2482, we inadvertently made the result of DefaultTimeZone observable. Previously, this AO's result was only surfaced indirectly:

• In Temporal: via CreateTemporalTimeZone and ToTemporalTimeZoneSlotValue. The ID is guaranteed to be in its canonical form whether it's an IANA named time zone identifier or an offset string.
• In Intl: via Intl.DateTimeFormat.prototype.resovledOptions().timeZone. The ID is guaranteed to be in its canonical form if it's an IANA zone, and if it's an offset string then it will throw until ECMA-402 supports offset time zones (see ECMA-402 should allow numeric-offset host time zones ecma402#683).

In both of the "indirectly exposed" cases above, if the system time zone is an IANA time zone, then it will be canonicalized. But if it's an offset string, then the spec is unclear about what will happen.

The spec text for DefaultTimeZone (both in 402 and in tc39/ecma262#3035 which should hopefully be merged soon) is clear that IANA time zones will be canonicalized. But both are silent about offset time zones. I'm open to adding a canonicalization step to that 262 AO later, e.g. in a normative PR or in proposal-canonical-tz, but wondering what to do in the meantime (or if that doesn't happen).

What should Temporal.Now.timeZoneId() do if the input is an offset string?

• Call CanonicalizeTimeZoneOffsetString, and remove that call if DefaultTimeZone adds a normalization step later?
• Assert it's already in normalized form, and remove the assertion if DefaultTimeZone adds an assertion later?
• Throw, and remove that throwing as part of 402's work to support offset strings? (ECMA-402 should allow numeric-offset host time zones ecma402#683) And remove that throwing if DefaultTimeZone throws later?

[ptomato]

I think this is something that the time zone canonicalization proposal should solve. Time zone identifier canonicalization currently isn't a thing in ECMA-262, only in ECMA-402, so there's nothing that Temporal could do about this in ECMA-262's DefaultTimeZone without bringing canonicalization to 262 — which would essentially mean absorbing the time zone canonicalization proposal.

I prefer your first bullet point, adding an assertion in DefaultTimeZone.

[justingrant]

Meeting 2023-05-25: We'll handle this by expanding the scope of proposal-canonical-tz (or perhaps by a separate normative PR to 262) to include a normative change to DefaultTimeZone that ensures that offset strings are in normal form before returning them.