-
Notifications
You must be signed in to change notification settings - Fork 154
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: Update calendar data consistency validation #2500
Normative: Update calendar data consistency validation #2500
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2500 +/- ##
==========================================
- Coverage 96.08% 96.07% -0.01%
==========================================
Files 20 20
Lines 11600 11655 +55
Branches 2195 2201 +6
==========================================
+ Hits 11146 11198 +52
- Misses 390 393 +3
Partials 64 64
|
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 editorial changes seem good in any case, could we get them in a separate PR?
In particular, "Editorial: Consolidate standard-field Calendar method logic into ECMA-262" is #1418, which I was planning on working on after getting all the normative issues finished. I realize it's later reverted in this PR, but it'd be great to put that work towards addressing that issue in a separate PR!
This looks to be less invasive than I thought it would be, so I'm more positive about it than I expected. It'd be helpful to me, if I could revisit it again once it's rebased.
a1af46b
to
7d1666d
Compare
22f90a3
to
a05869c
Compare
a05869c
to
8b967f1
Compare
8b967f1
to
0fd6708
Compare
0fd6708
to
28b99a6
Compare
28b99a6
to
e5fc09d
Compare
This is an editorial change intended to reduce the diff of PR #2500, where this rename is part of the changes.
This is an editorial change intended to reduce the diff of PR #2500, where this rename is part of the changes.
e5fc09d
to
5580db6
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.
I think this looks good, but I didn't spend enough time with it to be 100% confident so leaving for others to approve. A few minor comments below.
What's the plan with this PR? It's been open for a very long time. Is it still relevant? |
It's waiting on resolution of #2500 (comment) |
@gibson042, possible to respond to that comment so we can unblock this? Thx! |
b01d958
to
47a285b
Compare
Updated and rebased onto main. |
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.
Works for me, I'm fine to merge it along with tc39/test262#3835 when other reviewers are satisfied.
47a285b
to
bf1158f
Compare
Rebased. |
bf1158f
to
452d115
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.
Looks good to me! :)
"era" and "eraYear" are still checked in alphabetical order along with other fields when the calendar specifies their relevance, but ensuring both-or-neither and consistency between the pair and "year" is no longer part of the operation (although it remains part of CalendarResolveFields along with similar checks for "month" and "monthCode"). Fixes tc39#2465
…ds` algorithm Keep it in the implementation-defined CalendarFieldDescriptors operation
452d115
to
ecbe690
Compare
As of tc39/proposal-temporal#2500 , year is always optional for the ISO 8601 calendar.
As of tc39/proposal-temporal#2500 , year is always optional for the ISO 8601 calendar.
As of tc39/proposal-temporal#2500 , year is always optional for the ISO 8601 calendar.
As of tc39/proposal-temporal#2500 , year is always optional for the ISO 8601 calendar.
As of tc39/proposal-temporal#2500 , year is always optional for the ISO 8601 calendar.
Fixes #2497
Fixes #2465
Closes #2466
"era" and "eraYear" are still checked by PrepareTemporalFields in alphabetical order along with other fields when the calendar specifies their relevance, but ensuring both-or-neither and consistency between the pair and "year" is no longer part of the operation (although it remains part of CalendarResolveFields along with similar checks for "month" and "monthCode").
A followup should move Calendar-related operations from ECMA-402 to ECMA-262 after this and #2474... I initially included that here as 13e2c73, but backed it out to avoid potential merge conflicts.
TODO: