CreateTemporalZonedDateTime: Wrong argument type for "timeZone"

[anba]

CreateTemporalZonedDateTime:

timeZone (an available time zone identifier)

But timeZone can also be an offset time zone, so it's type should instead be "time zone identifiers".

[ptomato]

This seems correct as-is to me:

An available time zone identifier is either an available named time zone identifier or an offset time zone identifier.

Feel free to reopen if I overlooked something.

[justingrant]

Reopening. How does "available time zone identifier" differ from the existing term "time zone identifier" defined in current ECMA-262's time zone identifiers section? Based on my intent when I wrote that ECMA-262 text, it seeems like "available time zone identifier" is redundant and could be removed. But perhaps my 262 text was unclear, or you had something else in mind?

OTOH, there may (or may not) be a need for a new term for a time zone identifier in its normalized form, i.e. the result of ToTemporalTimeZoneIdentifier.

BTW, here's my mental map of the terms defined in ECMA-262, using bullet nesting to imply "IS A" relationships:

• time zone identifier
  • available named time zone identifier
    • primary time zone identifier
    • non-primary time zone identifier
  • offset time zone identifier

[anba]

Feel free to reopen if I overlooked something.

I've incorrectly treated available named time zones and available time zone identifier as the same type.

OTOH, there may (or may not) be a need for a new term for a time zone identifier in its normalized form, i.e. the result of ToTemporalTimeZoneIdentifier.

Is this covered by normalized format of a time zone identifier (defined in https://tc39.es/proposal-temporal/#sec-time-zone-identifiers)?

Temporal adds available time zone identifier as another subtype, so the relationships are now:

• time zone identifier
  • available time zone identifier
    • available named time zone identifier
      • primary time zone identifier
      • non-primary time zone identifier
    • offset time zone identifier

And for the actual time zones:

• time zone
  • available named time zone
  • offset time zone

[justingrant]

Temporal adds available time zone identifier as another subtype,

I don't understand (yet!) what is the delta between available time zone identifier and time zone identifier.

@ptomato could you clarify?

[ptomato]

Here is the difference as far as I understand it from https://tc39.es/proposal-temporal/#sec-time-zone-identifiers:

• time zone identifier: string composed entirely of code units in the inclusive interval from 0x0021 to 0x007E.
• available time zone identifier: either an available named time zone identifier or an offset time zone identifier

So all available time zone identifiers are time zone identifiers, but not vice versa. Examples of time zone identifiers that are not available time zone identifiers are:

• Etc/North_Pole
• +99:99
• !!!d3l3t3m3~~~

[justingrant]

time zone identifiers that are not available time zone identifiers

Do we really need this category, of strings that are syntactically valid but are not valid named or offset IDs? Why is that needed?

[ptomato]

I did a census of the places where it's used:

1. the input type of GetAvailableNamedTimeZoneIdentifier
2. the type of the [[Name]] field of the returned record from ParseTimeZoneIdentifier and ParseTemporalTimeZoneString
3. the type of the [[TimeZone]] field of Calendar Fields Record
4. in prose in 15.2 Use of the IANA Time Zone Database (2x)
5. in prose in the note after AvailableNamedTimeZoneIdentifiers
6. the type of the [[TimeZone]] slot of Intl.DateTimeFormat

Of these, I think (3), (4), and (6) are probably mistakes and should be available time zone identifier. The others seem correct and necessary to me, so I'm not sure we can get rid of it entirely.