Should `DTF.p.resolvedOptions().timeZone` canonicalize or not?

[justingrant]

This proposal recommends storing un-canonicalized Link identifiers in TimeZone and ZonedDateTime slots, and returning Link identifier strings from ZonedDateTime.p.timeZoneId, TimeZone.p.id, and toString/toJSON of both types.

But what about Intl.DateTimeFormat.p.resolvedOptions().timeZone?

Arguments for canonicalizing resolvedOptions().timeZone

• Backwards compatibility. Unlike Temporal that's brand new so little risk of breaking existing code by changing behavior, resolvedOptions().timeZone users might already have production code that expects canonicalization.
• resolvedOptions().timeZone is relatively undiscoverable so doesn't trigger as much user annoyance or confusion, compared with much more noticeable APIs like ZonedDateTime.p.toString() which every developer will see in browser dev tools, debuggers, logs, etc.
• We don't plan any other API (at least not initially) to fetch the canonical ID for a particular time zone. Leaving it in resolvedOptions().timeZone provides an escape hatch in case some users really do need this capability.

Arguments against canonicalizing resolvedOptions().timeZone

• More consistency with Temporal API behaviors; no user complaints/questions about why they're different
  • For example, developers porting their "get the timezone ID" code from resolvedOptions().timeZone to more ergonomic/discoverable/performant Temporal APIs won't get any different behavior
• Canonicalization is always a problem in every software platform. If it changes, users complain about their code breaking. If it doesn't change, users complain that it's out of date. So by removing canonicalization from as many APIs as possible, we reduce the impact of changes to canonicalization.
• If users need a canonicalization API, we could always add an ergonomic and discoverable one later, e.g. TimeZone.p.canonicalize(). But if we canonicalize resolvedOptions().timeZone differently from Temporal, we probably can't change this behavior later.

Personally I don't have a strong opinion either way. I'm inclined to follow whatever TG2 folks think is the best way to go.

[justingrant]

We discussed this question at today's TG2 meeting. @FrankYFTang noted that he needed to investigate whether this change would cause problems with DateTimeFormat, but that this investigation (like all implementation concerns) was appropriate to do during Stage 3 and would not block Stage 3 advancement.

[FrankYFTang]

@FrankYFTang noted that he needed to investigate whether this change would cause problems with DateTimeFormat, but that this investigation (like all implementation concerns) was appropriate to do during Stage 3 and would not block Stage 3 advancement.

to be specific - My comments during the TG2 meeting is about the change to step 29.e in InitializeDateTimeFormat