Editorial: Distinguish 'available time zone identifier'

[ptomato]

Temporal will introduce separate definitions for 'time zone identifier' (string consisting of characters that are legal in time zone identifiers) and 'available time zone identifier' (time zone identifier that is known to the implementation.)

For some usages it's probably more appropriate to speak of available time zone identifiers than time zone identifiers. For others, it's probably more appropriate to use 'available named time zone identifier' which is a definition given in ECMA-262.

[justingrant]

Good changes, thanks.

Dumb question: if "time zone identifier" is just a string that satisfies a particular syntax, then why not just use the syntax-directed operation (not sure if I'm using that term correctly) instead of a custom-defined term? This would make it obvious to readers that you're just talking about a string with valid syntax, rather than any actual meaningful identifier.

[sffc]

Will this show up as a definition link like "mathematical value" for example?

[ptomato]

Will this show up as a definition link like "mathematical value" for example?

It will eventually. We'd need to add the definition "An available time zone identifier is either an available named time zone identifier or an offset time zone identifier." to https://tc39.es/ecma262/#sec-time-zone-identifiers. This addition is part of Temporal, but we could upstream that sentence into ECMA-262 earlier if need be.

Dumb question: if "time zone identifier" is just a string that satisfies a particular syntax, then why not just use the syntax-directed operation (not sure if I'm using that term correctly) instead of a custom-defined term? This would make it obvious to readers that you're just talking about a string with valid syntax, rather than any actual meaningful identifier.

You can't tell just from the syntax whether a time zone identifier is available or not, you need the TZDB. We could write a syntax-directed operation that says to consult the TZDB, but I suspect implementations would object to that because it'd complicate the dependencies of their parsers.

[justingrant]

Dumb question: if "time zone identifier" is just a string that satisfies a particular syntax, then why not just use the syntax-directed operation (not sure if I'm using that term correctly) instead of a custom-defined term? This would make it obvious to readers that you're just talking about a string with valid syntax, rather than any actual meaningful identifier.

You can't tell just from the syntax whether a time zone identifier is available or not, you need the TZDB. We could write a syntax-directed operation that says to consult the TZDB, but I suspect implementations would object to that because it'd complicate the dependencies of their parsers.

Sorry, I was talking about "time zone identifier" not "available time zone identifier". The former is just syntax, right? So can we call it something like "a TimeZoneIdentifier Parse Node" in the spec so it's clear that it's just syntax? Like this?

I'm pushing on this because I think "time zone identifier" vs. "available time zone identifier" feels confusingly similar to each other, and by more clearly calling out that one is just syntax, then it removes that potential source of confusion.

[gibson042]

The changes as-is look good to me, although I would not necessarily object to more iteration. @justingrant's point about similarity is valid, and elsewhere in ECMA-402 we do have the concept of a "structurally valid language tag", which is broader than the list of supported locale identifiers that appear in an Available Locales List.

[ptomato]

I quite like the idea of "structurally valid time zone identifier", does that make it clear enough that it's parseable but not necessarily available?

[ptomato]

We'd probably have to define that in ECMA-262, though: https://tc39.es/ecma262/#sec-time-zone-identifiers The advantage of keeping "time zone identifier" for now, is that we wouldn't need to block this PR.

If we agree here that "structurally valid time zone identifier" is good, my preference would be to introduce that in ECMA-262 first, and when that makes it through the editing process I'll write PRs for ECMA-402 and Temporal using the new terminology. In the meantime, we could merge this PR.

[sffc]

+1 for qualifying all instances of "time zone identifier".

Sounds like we will have 3? "structurally valid", "available", and "primary"?

[justingrant]

+1 for qualifying all instances of "time zone identifier".

Sounds like we will have 3? "structurally valid", "available", and "primary"?

There's also "non-primary".

If we agree here that "structurally valid time zone identifier" is good, my preference would be to introduce that in ECMA-262 first, and when that makes it through the editing process I'll write PRs for ECMA-402 and Temporal using the new terminology. In the meantime, we could merge this PR.

I admit that I'm not convinced that there's a need for a new term. This space is already jumbled with different terms with names that are very similar to each other.

How many uses of this term will exist? If only a few, can we just say something like this?

a string that when passed to ParseText returns a Parse Node for the TimeZoneIdentifier goal symbol"

I also don't prefer "available time zone identifier" because it's so similar to "available named time zone identifier". Seems fine to just say "available named time zone identifier or an offset time zone identifier" if we only need it in a few places.

[gibson042]

In terms of sets and relationships (and using maximally precise names without committing to them), we have

• available named time zone identifier = primary available named time zone identifier ∪ non-primary available named time zone identifier ∪ offset time zone identifier
• "UTC" ∈ primary available named time zone identifier
• primary available named time zone identifier ∩ non-primary available named time zone identifier = ∅
• primary available named time zone identifier ⊆ structurally valid named time zone identifier
• non-primary available named time zone identifier ⊊ structurally valid named time zone identifier (this is a strict subset because "UTC" is required to be primary)
• offset time zone identifier ∩ structurally valid named time zone identifier = ∅