Editorial: Use early errors and parameterization to simplify ISO 8601 grammar #2766
Conversation
This file contains 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 ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2766 +/- ##
==========================================
+ Coverage 96.51% 96.57% +0.06%
==========================================
Files 23 23
Lines 12386 12243 -143
Branches 2294 2268 -26
==========================================
- Hits 11954 11824 -130
+ Misses 372 358 -14
- Partials 60 61 +1 ☔ View full report in Codecov by Sentry. |
Dates such as 2019-02-29, 2024-09-31, etc., can be rejected at early error time. (This changes the order in which some errors are thrown, but since they are all RangeError, it is not observable from the spec's point of view.)
Previously the grammar relied on bizarre one-off productions such as TimeSpecWithOptionalOffsetNotAmbiguous and DateMonthWithThirtyOneDays, to prevent time strings such as 0119 (01:19 but ambiguous with 19th January) or 1524-08 (15:24 at -08:00 from UTC, but ambiguous with August of 1524) from parsing correctly without a time designator. By using early errors, these confusing productions are no longer necessary to achieve the desired result. Closes: #1984
TimeSeparator[Extended] is defined in ECMA-262 and we can use it here instead of notation like `:`?. We define a new production Time which is a TimeSpec that is either fully basic or fully extended. In AnnotatedTime we keep it split out when there is no TimeDesignator present, because the early error only applies to the [~Extended] case.
Similar to TimeSeparator[Extended] in ECMA-262, introduce DateSeparator, and Date to denote a DateSpec either fully in basic format or fully in extended format.
…owed In Plain types, the UTC designator 'Z' is not allowed in the string. This was previously expressed with explicit checks in the ParseTemporal... AOs, but can be more cleanly expressed with a [Plain] parameter to the DateTimeUTCOffset production.
…meterization Another place where we can deduplicate parts of the grammar.
Instead of two separate productions UTCOffsetSubMinutePrecision and UTCOffsetMinutePrecision, we can have one UTCOffset production with a SubMinutePrecision parameter.
ptomato
force-pushed
the
1984-early-errors-and-parameterization
branch
from
f9cf3f0
to
67fb2fd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 the ISO 8601 grammar, we can use early errors and parameterization to avoid such bizarre productions like TimeHourNotThirtyOneDayMonth and TimeSpecWithOptionalOffsetNotAmbiguous, etc.
Best reviewed commit by commit.
Closes: #1984