`TimeZone.from` with ISO strings that have both Z and IANA name

[justingrant]

Temporal.TimeZone.from("2021-01-05T16:37:40.840192769Z[Asia/Tokyo]");
// no exception??? TimeZone {_repr_: "Temporal.TimeZone <UTC>"}

This behavior matches the spec, but:

• It seems really weird for the Z to win out over the explicit time zone annotation. I can't imagine the current behavior would ever be the caller's intent.
• This behavior seems contrary to the champions decision in Clarify TimeZone.from() #313 (comment), where a Z + IANA format was not shown in the list of acceptable formats.
• This string, if passed to ZonedDateTime.from, should throw according to the spec, although IETF and interop concerns might prompt us to accept this format-- see ZonedDateTime.from when the offset is "Z" (and an IANA name is present) #1695 for discussion.

IMHO this is a spec bug and seems worth a normative change. Returning the UTC timezone seems clearly misaligned with the caller's intention here. I think the correct behavior is to return a TimeZone created using the bracketed timezone annotation. (Or perhaps to throw depending on resolution of #1695.) UPDATE: Per 2020-08-21 decision in #1695, we'll accept this format in ZonedDateTime.from too.

[ljharb]

If there's both, should it throw since it's potentially ambiguous?

[justingrant]

If there's both, should it throw since it's potentially ambiguous?

In context of a string like 2021-01-05T16:37:40Z[Asia/Tokyo], "Z" is not a time zone, it's an offset. It's not any more ambiguous than 2021-01-05T16:37:40+00:00[Europe/London] where the offset of +00:00 is used but the time zone is "Europe/London". But TimeZone.from with "+00:00[Europe/London]" (or any other string using a non-Z offset and a bracketed identifier) returns the bracketed time zone, not the offset. Example:

Temporal.TimeZone.from('2021-01-05T16:37:40+00:00[Europe/London]');
// => Temporal.TimeZone <Europe/London>

"Z" is arguably less ambiguous than other offsets, because other offsets potentially represent real slices of the Earth, while "Z" is essentially the null of time zones. It's an assertion that the data has no time zone information attached. This is why Z is used in the toString() output of Temporal.Instant which by definition is a timezone-less value that is unmoored from any real place on Earth.

All that said, if the user really wants to get a Temporal.TimeZone using an offset, then they can strip off the bracketed identifier:

Temporal.TimeZone.from('2021-01-05T16:37:40+00:00');
// => Temporal.TimeZone <+00:00>
Temporal.TimeZone.from('2021-01-05T16:37:40Z');
// => Temporal.TimeZone <UTC>

[justingrant]

Meeting 2020-08-21: This is a spec bug that's contrary to the champions' earlier decisions and to the intuition of average developers. We'll make a normative change to use the bracketed annotation, not the Z, to create the new TimeZone instance.