-
Notifications
You must be signed in to change notification settings - Fork 105
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
Normative: specify time zone ID requirements to reduce divergence between engines #877
Conversation
aa65347
to
3ea9cee
Compare
3ea9cee
to
6a544eb
Compare
Thanks for putting this together @justingrant! We can discuss this at the next TG2 meeting. In the mean time, I encourage the listed reviewers to take a look. |
It's fine to submit tests to test262 that no engine can pass yet, as long as they are correct according to the current snapshot of ECMA-262 or 402 or a Stage 3 proposal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel qualified to review the details — I mostly haven't followed those discussions. At a general level, this all looks very reasonable.
c78de1d
to
3bb6dee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly editorial comments, but I am not comfortable with making the rename waiting period mandatory.
I assuem you mean to say "e.g. PST8PDT=>America/Los_Angeles" ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The algorithm looks good, but I'd like to use more precise phrasing than «the first, space-delimited column in backzoneLinkLine after…».
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Some final tweaks to StringSplitToList and its use, then I think this is ready.
dc691aa
to
b177cec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to update StringSplitToList to support empty-string S (with result in alignment with String.prototype.split, e.g. « "" »), I would not be opposed. But dealing with it at call sites for now seems fine to me.
8e1198a
to
adc0cf3
Compare
Nah, I think it's fine as-is, and I actually think it's kinda good bad to force callsites to decide how they want to handle the empty-string case because it's not always intuitive how to handle that case. Anyway, I adopted both of your last suggestions, rebased, and squashed. I think this PR should be ready to merge. |
Actually, I assume we want Test262 tests for this new text. I'll start working on those. And of course it can't be merged until after it's approved at the next TC39 meeting in a few weeks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, let's save the IsWellFormedUnitIdentifier changes for a followup. This PR ought to be narrowly focused on time zones, and IsWellFormedUnitIdentifier is not the only preexisting operation that will benefit from StringSplitToList.
6273e7f
to
9be09da
Compare
This PR resolves tc39#825 by adding spec text that more clearly 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 and CLDR while providing deterministic rules that can guide future changes in CLDR data. Finally, this PR introduces a new StringSplitToList abstract operation and uses it to simplify AvailableNamedTimeZoneIdentifiers and IsWellFormedUnitIdentifier.
9be09da
to
d6852fa
Compare
OK, I reverted that part. I think this PR should be ready to present at Helsinki, unless there's other review feedback. Thanks @gibson042 for your help whipping this into shape! |
Add agenda item for: Normative: specify time zone ID requirements to reduce divergence between engines tc39/ecma402#877
Add agenda item for: Normative: specify time zone ID requirements to reduce divergence between engines tc39/ecma402#877
I believe this got TG1 consensus in June 2024. @justingrant Is this ready to merge, or should we wait for CLDR-17111? |
AFAIK this is ready to merge. It lacks Test262 tests, but I assume these can be added later? |
@ben-allen If this is ready to merge, please merge it :) |
This proposed change resolves #825 by adding normative spec text to clarify how ECMA-402 implementations should decide which IANA time zone IDs should be primary vs. non-primary. This will enable more consistency between ECMAScript implementations and prevent future divergence.
This PR also accommodates to web reality by aligning ECMA-402 with CLDR and ICU. This should make it easier for all ECMAScript engines to comply with the spec while still being able to use ICU.
This PR is stacked on #876, so please ignore the first commit when reviewing this PR.
Note that the problem of out-of-date primary IDs for renamed Zones (like Asia/Calcutta) is out of scope to this PR, because the spec already requires current IDs, and there's already a plan to fix it that requires no spec changes.
Summary of proposed changes
This PR implements "Option C" in #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.
We'll start with a baseline of IANA's Zone and Link names and specify a few exceptions:
This PR also makes two other smaller text changes that we expect to have zero impact on current engines:
Per-engine changes required
Implementing the changes in this PR will impact JS engines differently, given the current divergence between engines:
For V8 (cc @FrankYFTang) and JSC (cc @Constellation), there should be no change because they rely on ICU and CLDR which already behave like 1-3 above. Note that this PR doesn't affect the plan to fix out-of-date canonicalizations like Asia/Calcutta and Europe/Kiev. This plan is unchanged: as part of landing Temporal Stage 4, switch to use ICU's new
icu::TimeZone::getIanaID()
, which returns the latest IANA IDs instead of out-of-date canonical IDs like Asia/Calcutta.For SpiderMonkey (cc @anba), more changes are needed because currently SpiderMonkey conforms to the spec which requires using
backward
in TZDB to determine canonicalization. SM could useicu::TimeZone::getIanaID()
to implement (2) and (3) above, or could implement the same behavior by reading CLDR data or IANA data directly. Also, this PR will reduce SM's differences inIntl.supportedValuesOf('timeZone')
vs. V8/JSC.Testing
Test262 changes will be needed to validate these normative changes, but I'm not sure how we can run those tests except using the Temporal polyfill. @ptomato I'll be looking for your advice (and perhaps help writing tests!) on this point.
Feedback requested
Feedback is welcome on any part of this proposal, but I'm most interested in making sure that the spec text actually accomplishes what the summary above claims that it does.