Editorial: align time zone identifier text and AOs with ECMA-262#876
Merged
Editorial: align time zone identifier text and AOs with ECMA-262#876
Conversation
This was referenced Mar 31, 2024
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
Mar 31, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
Mar 31, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
Mar 31, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
justingrant
added
editorial
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
Apr 3, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
This PR updates ECMA-402 spec text to align with current ECMA-262 terminology and AOs for time zone identifiers. Changes include: * Replaces `DefaultTimeZone`, `CanonicalizeTimeZoneName`, and `IsValidTimeZoneName` with calls to current ECMA-262 abstract operations. * Refactors `AvailableCanonicalTimeZones` to call new ECMA-262 AOs, and renames it to `AvailablePrimaryTimeZoneIdentifiers`. * Adds a `GetAvailableNamedTimeZoneIdentifier` AO Temporal will eventually merge into ECMA-262, but it's not there yet so we need a copy here. * Replaces `#sec-time-zone-names with a "Use of the IANA Time Zone Database" section that extends ECMA-262's #sec-time-zone-identifiers section. * Adds a few paragraphs of editorial recommendations (borrowed from Temporal) about managing updates and builds of TZDB.
justingrant
force-pushed
the
refactor-time-zone-text
branch
from
970f1b1 to
85c81cd
Compare
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
Apr 3, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
Apr 3, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
Apr 3, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
Contributor
Author
|
@sffc @gibson042 what is the process for ECMA-402 editorial PRs? I'd like to ideally get this reviewed before it gets too stale. |
Contributor
|
The process is to get a review from @gibson042 or @ben-allen. |
Contributor
Author
@gibson042 @ben-allen Possible to review this before it gets too stale? Thanks! |
ben-allen
approved these changes
Apr 25, 2024
Contributor
ben-allen
left a comment
ben-allen
left a comment
There was a problem hiding this comment.
This seems both entirely sound and entirely clear. I trust @ptomato on all language derived from Temporal, and can't find any spec bugs.
Thank you for all your work on time zone names in general -- it's genuinely geopolitically important to get this right.
ptomato
added a commit
to ptomato/ecma402
that referenced
this pull request
May 8, 2024
AvailableCalendars should return all possible aliases, so that other places in the spec (e.g. in the future, validating a string calendar ID in Temporal) can use them to determine whether a given input value is valid. This input value can subsequently be canonicalized by another abstract operation, CanonicalizeCalendar. In Intl.supportedValuesOf(), on the other hand, we should not return all possible aliases, so we filter them out using CanonicalizeCalendar before returning the list of AvailableCalendars codes as an array to the caller. See tc39/proposal-intl-enumeration#49. This is the part of that PR that I consider relevant for the future integration of Temporal. The time zone parts were already done as part of tc39#876. If desired, I could implement the rest of that PR, adding CanonicalizeCollation, CanonicalizeCurrency, CanonicalizeNumberingSystem, and CanonicalizeUnit as well. Closes: tc39#726
justingrant
added a commit
to justingrant/ecma402
that referenced
this pull request
May 22, 2024
This PR resolves tc39#825 by adding spec text that defines how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This PR implements "Option C" in tc39#825 by deterministically defining ECMAScript's exceptions from the IANA Time Zone Database's defaults, and then pointing implementers at ICU as a convenient implementation of those exceptions. This PR also accommodates to web reality by aligning the 402 spec text with the existing behavior of ICU. This PR is stacked on top of tc39#876.
ptomato
added a commit
to ptomato/ecma402
that referenced
this pull request
Jun 4, 2024
AvailableCalendars should return all possible aliases, so that other places in the spec (e.g. in the future, validating a string calendar ID in Temporal) can use them to determine whether a given input value is valid. This input value can subsequently be canonicalized by another abstract operation, CanonicalizeUValue, which we can use in several other places. In Intl.supportedValuesOf(), on the other hand, we should not return all possible aliases, so we filter them out using CanonicalizeUValue before returning the list of AvailableCalendars codes as an array to the caller. See tc39/proposal-intl-enumeration#49. This is the part of that PR that I consider relevant for the future integration of Temporal. The time zone parts were already done as part of tc39#876. If desired, I could implement the rest of that PR, adding CanonicalizeCollation, CanonicalizeCurrency, CanonicalizeNumberingSystem, and CanonicalizeUnit as well. Closes: tc39#726
gibson042
pushed a commit
to ptomato/ecma402
that referenced
this pull request
Jun 4, 2024
AvailableCalendars should return all possible aliases, so that other places in the spec (e.g. in the future, validating a string calendar ID in Temporal) can use them to determine whether a given input value is valid. This input value can subsequently be canonicalized by another abstract operation, CanonicalizeUValue, which we can use in several other places. In Intl.supportedValuesOf(), on the other hand, we should not return all possible aliases, so we filter them out using CanonicalizeUValue before returning the list of AvailableCalendars codes as an array to the caller. See tc39/proposal-intl-enumeration#49. This is the part of that PR that I consider relevant for the future integration of Temporal. The time zone parts were already done as part of tc39#876. If desired, I could implement the rest of that PR, additionally supporting collation, currency, numbering system, and unit canonicalization. Closes: tc39#726
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR updates ECMA-402 spec text to align with current ECMA-262 terminology and AOs for time zone identifiers. Changes include:
DefaultTimeZone,CanonicalizeTimeZoneName, andIsValidTimeZoneNamewith calls to current ECMA-262 abstract operations.AvailableCanonicalTimeZonesto call new ECMA-262 AOs, and renames it toAvailablePrimaryTimeZoneIdentifiers.GetAvailableNamedTimeZoneIdentifierAO Temporal will eventually merge into ECMA-262, but it's not there yet so we need a copy here.#sec-time-zone-nameswith a "Use of the IANA Time Zone Database" section that extends ECMA-262's#sec-time-zone-identifierssection.