Proposal-temporal: Clarify TimeZone.from()

[ptomato]

In https://tc39.es/proposal-temporal/#sec-temporal-timezonefromstring we need to clarify how Temporal.TimeZone.from() works. Currently as specified (with the regex) it will take either a Temporal.TimeZone object or an ISO string (plus timezone in brackets), and throw otherwise.

As implemented in the polyfill, it will take a time zone identifier string, the same as passed to new Temporal.TimeZone().

Examples of what would be accepted by the current spec:

• 2020-01-14T00:31:00.065858086Z → UTC
• Z → UTC
• 2020-01-13T16:31:00.065858086-08:00 → -08:00
• -08:00 → -08:00
• 2020-01-13T16:31:00.065858086-08:00[America/Vancouver] → America/Vancouver
• -08:00[America/Vancouver] → America/Vancouver

Examples of what would currently not be accepted by the spec but would by the polyfill:

• UTC
• America/Vancouver

(This is in addition to #312 to specify it otherwise than with a regex)

[littledan]

Hmm, this seems like an error in the spec. I think it's important that things like UTC and America/Vancouver be accepted by the spec and polyfill. On the other hand, I'd be curious to learn the motivation for accepting these ISO strings; is this documented anywhere?

[ptomato]

My guess at the motivation was so that you could pass an ISO string that you got from elsewhere directly into any of the from()s and it would just work.

It seems a bit weird to accept the single letter Z but on the other hand also consistent with chopping the date and time parts off of the ISO string.

[gibson042]

I am mildly surprised that "-08:00[America/Vancouver]" is accepted, and very surprised that "Z" is. If we're going to allow from to extract time elements from date-time strings, shouldn't those strings be _valid_ (e.g., accepted by Temporal.DateTime.from)? It seems like the domain of accepted input for any particular from method should be the union of input that is deemed acceptable for all from methods and a collection of special cases for its particular type (and I can't imagine wanting "Z" as a special case for Temporal.TimeZone.from—not that I think "-08:00[America/Vancouver]" should be accepted either, although I could imagine a case being made for it).

[ptomato]

So the case that you're making is that TimeZone.from() should accept whatever new TimeZone() accepts, as well as valid ISO strings with a time zone, optionally extended with a bracketed time zone name? And that ISO strings with the date and time chopped off are not valid ISO strings?

That implies 2020-01-14T00:31:00.065858086Z, 2020-01-13T16:31:00.065858086-08:00, and 2020-01-13T16:31:00.065858086-08:00[America/Vancouver] would be in due to being valid (extended) ISO strings; UTC, -08:00, and America/Vancouver would be in due to being accepted by the constructor; and Z and -08:00[America/Vancouver] would be out. That seems reasonable to me.

[gibson042]

Yes, those results seem reasonable to me as well.

[ljharb]

However, I think new TimeZone() should probably not accept another TimeZone object, where TimeZone.from should.

[pipobscure]

Originally the .from methods were intended as simple casts. However we have since agreed that it is more of a factory method that also does string parsing.

In short it should parse anything valid.

That means the Time Zone component of an ISO string (including Z) as well as the pure offset string and IANA-Name.

The constructor should be strict in contrast. It should accept a pure offset string or IANA-Name only.

[littledan]

Originally the .from methods were intended as simple casts.

Sorry, which proposal draft do you mean by "originally"? Going further back, there were a bunch of different fromXyz methods. I wonder if it'd make sense to return to that, if string parsing in from is getting complicated and branchy. We could have fromTimeZoneName and fromTimeString methods that are separate, for example. (If we do it for timezone, we might want to do it for other classes as well...)

[ptomato]

(To clarify, I'm not proposing to change the fact that TimeZone.from() accepts a TimeZone object — only to discuss which strings it should/shouldn't accept)

[ptomato]

According to the principles proposed by @pipobscure in https://github.com/tc39/proposal-temporal/issues/198#issuecomment-547552203 we _should_ actually support Z and -08:00[America/Vancouver], namely because of the following:

• The timezone designator may be extended by [<IANA>] zones to properly designate timezones
• Dates/Times/TimeZones may occur individually or in combination

[gibson042]

Originally the .from methods were intended as simple casts. However we have since agreed that it is more of a factory method that also does string parsing.

In short it should parse anything valid.

That means the _Time Zone_ component of an ISO string (including Z) as well as the pure offset string and IANA-Name.

The constructor should be strict in contrast. It should accept a pure offset string or IANA-Name only.

It sounds like you're arguing that because "-08:00[America/Vancouver]" and "Z" are valid _inside_ extended ISO 8601 strings accepted by e.g. Temporal.DateTime.from, they should be accepted _in isolation_ by Temporal.TimeZone.from. That doesn't hold water for me, because those elements don't make sense out of context. And it's not even clear what use case would benefit from accepting them... what is motivating the complexity?

[ptomato]

In the above pull request I've initially made it so that Z and -08:00[America/Vancouver] continue to be accepted, since that's the most conservative change. I can amend it if we decide the other way, or we can punt that to a separate issue.

[littledan]

Let's discuss this issue in the next Temporal call. I'd like to consider moving in the direction I mentioned at https://github.com/tc39/proposal-temporal/issues/313#issuecomment-576290371 . I think it's a mistake to accept multiple different grammars in the same method which parses a string.

[pipobscure]

I guess we are talking about the lines https://github.com/tc39/proposal-temporal/pull/321/files#diff-f8c7e572d5e8b4853c7884ffbbbb8e16R81-R85 from the PR.

I think those are merely remnants that shouldn't match on their own (only as part of a full ISO string). I think you may just have uncovered a bug in the polyfill. I don't think we ever made an explicit choice to have those work/

[littledan]

@pipobscure How do you think it should work? I think I'm disagreeing with your comment on this particular issue, but maybe I am misunderstanding you.

[pipobscure]

@pipobscure How do you think it _should_ work? I think I'm disagreeing with your comment on this particular issue, but maybe I am misunderstanding you.

I think the acceptable strings for TimeZone should be:

1. A full ISO-8601 date-time with a Zulu timezone indicator: 1976-11-18T14:23:30.123Z
2. A full ISO-8601 date-time with an offset part: 1976-11-18T15:23:30.123+01:00
3. A full ISO-8601 date-time with an offset and Iana name: 1976-11-18T15:23:30.123+01:00[Europe/Vienna] (in this case the TimeZone is Europe/Vienna and the offset is used to verify as in throw if the date-time in that IANA zone does not exists with the specified offset)
4. A simple offset string +01:00 or +0100
5. An IANA name Europe/Vienna, UTC, America/New_York

So while Z is OK as part of an ISO-8601 date-time it's not if it's just Z.

[ptomato]

Meeting Jan. 27: We'll go with above proposal. Some concerns about mixing two different grammars in from(), maybe we should go back to fromString() etc. but that should be revisited separately if necessary.