Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CreateTemporalZonedDateTime: Wrong argument type for "timeZone" #3055

Open
anba opened this issue Dec 9, 2024 · 4 comments
Open

CreateTemporalZonedDateTime: Wrong argument type for "timeZone" #3055

anba opened this issue Dec 9, 2024 · 4 comments

Comments

@anba
Copy link
Contributor

anba commented Dec 9, 2024

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
Copy link
Collaborator

ptomato commented Dec 10, 2024

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.

@ptomato ptomato closed this as not planned Won't fix, can't repro, duplicate, stale Dec 10, 2024
@justingrant justingrant reopened this Dec 13, 2024
@justingrant
Copy link
Collaborator

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
Copy link
Contributor Author

anba commented Dec 13, 2024

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
Copy link
Collaborator

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants