Normative: Reject '-000000' as extended year #1992
Merged
Conversation
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
Codecov Report
@@ Coverage Diff @@
## main #1992 +/- ##
==========================================
- Coverage 94.97% 94.62% -0.36%
==========================================
Files 19 19
Lines 10990 10992 +2
Branches 1750 1598 -152
==========================================
- Hits 10438 10401 -37
- Misses 535 573 +38
- Partials 17 18 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
closing because this change belongs in PR #1992 |
ptomato
approved these changes
Jan 12, 2022
ptomato
changed the title
|
Just for the record: This is a normative change, but it was already "pre-approved" at the October 2021 meeting of TC39: https://github.com/tc39/notes/blob/master/meetings/2021-10/oct-25.md#clarify-validity-of-negative-expanded-year-0 |
In [1] we raised the question of whether "-000000" should be accepted as an extended year. The discussion there was focused on parsing ISO 8601 dates, where "-000000" shows up as the year part of a potentially complicated string. But what about simpler strings, more precisely, year-month strings like "2022-01"? I think it is reasonable to infer from the discussion in [1] that "-000000" should be rejected as the year part of Temporal PlainYearMonths. If that's right, for consistency's sake, we ought to change `ParseTemporalYearMonthString` so that "-000000" gets rejected, just as "-000000" is supposed to be rejected when parsing date(-time) strings more complicated than year-months (and which use a different abstract operation). Temporal has an abstract operation, `ParseTemporalYearMonthString`, for parsing year-month strings. It is simpler than parsing the full ISO 8601 grammar. As it currently stands, "-000000" sneaks through and is not rejected. Thus, "-000000-07" is not rejected as a Temporal PlainYearMonth. 1: tc39#1753
|
The PR has been extended to handle the case of |
ljharb
reviewed
Jan 31, 2022
Co-authored-by: Jordan Harband <[email protected]>
Co-authored-by: Jordan Harband <[email protected]>
|
@ljharb I didn't know about |
|
I reviewed the update, I think this is ready to go now. |
12wrigja
added a commit
to 12wrigja/temporal-polyfill
that referenced
this pull request
Mar 4, 2022
12wrigja
added a commit
to 12wrigja/temporal-polyfill
that referenced
this pull request
Mar 4, 2022
12wrigja
added a commit
to 12wrigja/temporal-polyfill
that referenced
this pull request
Mar 4, 2022
toJSON. Reject '-000000' as an extended year value. Bump test262. Port of tc39/proposal-temporal#1995. Port of tc39/proposal-temporal#1992
webkit-commit-queue
pushed a commit
to WebKit/WebKit
that referenced
this pull request
May 10, 2022
https://bugs.webkit.org/show_bug.cgi?id=240263 Reviewed by Yusuke Suzuki. As of the following two PRs, -000000 is officially disallowed as a representation of the year zero in ISO date strings. tc39/ecma262#2550 tc39/proposal-temporal#1992 This patch implements the change for Temporal and Date alike. * test262/expectations.yaml: Mark 24 test cases as passing. * runtime/ISO8601.cpp: (JSC::ISO8601::parseDate): * wtf/DateMath.cpp: (WTF::parseES5DatePortion): Canonical link: https://commits.webkit.org/250432@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@293996 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
In #1753 there was some discussion of what to do about dates with an extended year equal to "-000000". It was decided to reject such cases. Here's a simple solution to that.
Alternatives considered:
closes #1753