-
Notifications
You must be signed in to change notification settings - Fork 172
Remove zoneRequired
option in ParseTemporalTimeZoneString & better align parsing to spec
#1979
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
Remove zoneRequired
option in ParseTemporalTimeZoneString & better align parsing to spec
#1979
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1979 +/- ##
==========================================
+ Coverage 94.98% 94.99% +0.01%
==========================================
Files 19 19
Lines 10943 10939 -4
Branches 1739 1739
==========================================
- Hits 10394 10392 -2
+ Misses 533 531 -2
Partials 16 16
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
👍
polyfill/lib/ecmascript.mjs
Outdated
ParseTemporalInstantString: (isoString) => { | ||
return ES.ParseISODateTime(isoString, { zoneRequired: true }); | ||
const result = ES.ParseISODateTime(isoString); | ||
if (!result || (!result.z && !result.offset)) throw new RangeError('Temporal.Instant requires a time zone offset'); |
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.
Do we need !result
here? It seems like an object will always be returned. (Same comment goes for ParseTemporalZonedDateTimeString below)
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.
Whoops, must have been left over from a previous go at solving this problem with the same "return false" pattern that we're actually removing. I'll remove and then merge.
The `zoneRequired` option in ParseTemporalTimeZoneString doesn't work, because the `zonesplit` regex in regex.mjs matches any string. (It does correctly match each component, it just doesn't fail if none match.) Furthermore, callers of this option don't really follow the spec that requires throwing as soon as we know that it's not the right regex for the type. This commit fixes tc39#1973 by: * Removing the `zoneRequired` option * Removing the now-unused `datetime` regex, and renaming the `instant` regex to `zoneddatetime` to better reflect what it's doing. * Refactoring a few of the parsing methods to better match the spec, which expects that strings that don't satisfy the production will throw before doing non-parsing work. After this commit, every `Parse*` method will throw if the string doesn't match the production for that type.
050aa56
to
9fafb23
Compare
The
zoneRequired
option inES.ParseTemporalTimeZoneString
doesn't work, because thezonesplit
regex in regex.mjs matches any string. (It does correctly match each component, it just doesn't fail if none match.) Furthermore, callers of this option don't really follow the spec that requires throwing as soon as we know that it's not the right regex for the type.This PR fixes #1973 by:
zoneRequired
optiondatetime
regex, and renaming theinstant
regex tozoneddatetime
to better reflect what it's doing.Parse*
AO will throw if the string doesn't match the production for that type.