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.