WIP: Add proposals for resolving questions with from()/Temporal.parse() #503
Conversation
docs/parse-draft.md
Outdated
|
|
||
| Use cases we identified: | ||
|
|
||
| 1. Parse an ISO 8601 string and get the exact information that is mandated by ISO 8601, which means that the whole string is relevant. (24:00 is midnight the following day, :60 seconds are coerced to :59). |
There was a problem hiding this comment.
This already gums up the works a bit, because seconds 60 is valid ISO 8601 but not representable in Temporal, and hours 24 is invalid but accepted by ECMAScript Date. So there are arguments for (at least sometimes, perhaps under author control?) rejecting the first as out of range and rejecting the second as invalid. Being liberal without opt-in strictness could stymie well-intentioned code.
There was a problem hiding this comment.
FWIW, hours 24 is valid ISO 8601 (and was added to the RFC 3339 grammar in an erratum.) I should elaborate here to say that what I mean by "parse an ISO 8601 string" is really "parse a string that conforms to our particular subset and interpretation of ISO 8601". In another pull request (#404, which I think can't be merged until this issue is resolved) I've made an attempt at specifying that format exactly.
There was a problem hiding this comment.
FWIW, hours 24 is valid ISO 8601 (and was added to the RFC 3339 grammar in an erratum.)
My understanding is that it's only valid in time intervals.
The end of day representation, where [hh] has a value of [24], shall not be used for a single time point.
I should elaborate here to say that what I mean by "parse an ISO 8601 string" is really "parse a string that conforms to our particular subset and interpretation of ISO 8601". In another pull request (#404, which I think can't be merged until this issue is resolved)
That makes sense, but I'm pointing out that there can be problems when the ECMAScript interpretation differs from author requirements in a way that is difficult or impossible to correct.
| time24 = '2020-04-07T24:00:00-07:00[America/Vancouver]'; | ||
|
|
||
| // Invalid time zone (although valid ISO 8601 string) | ||
| invalidZone = '2001-09-08T18:46:40+01:00[America/Vancouver]'; |
There was a problem hiding this comment.
This case is particularly interesting, because there are cases where you can't know if the offset is valid or invalid for the time zone (or where you can "know" but be wrong), e.g. 2019-12-15T10:23-02:00[America/Sao_Paulo] was valid per 2019a tz data (announced March 2019), but not valid per 2019b (announced July 2019) because Brazil stopped observing Daylight Saving Time. Being strict without an escape hatch could also stymie well-intentioned code.
There was a problem hiding this comment.
I originally thought that the escape hatch would be Temporal.parse. But I agree with you, that is too cumbersome when parsing serialized strings that may have been invalidated by political changes since the time when they were serialized. I'll change this.
Temporal.Absolute would still need to consider both the offset and the IANA name, to be able to disambiguate in the case of a wall-clock time that is repeated in a DST transition.
There was a problem hiding this comment.
That was the motivation for the disambiguation parameter in the original Temporal.Absolute.fromString.
Because there are three valid parsing scenarios:
- IANA & Offset have to match (default)
- Use the IANA-Zone and only use offset to disambiguate
- Use the Offset and ignore IANA
There was a problem hiding this comment.
Hmm, (3) is not covered in this proposal for how Temporal.parse() works ... I'll revise it to make sure the offset is accessible separately.
Codecov Report
@@ Coverage Diff @@
## main #503 +/- ##
=======================================
Coverage 96.83% 96.83%
=======================================
Files 17 17
Lines 3953 3953
Branches 582 582
=======================================
Hits 3828 3828
Misses 123 123
Partials 2 2
Continue to review full report at Codecov.
|
ptomato
force-pushed
the
428-from-parse
branch
2 times, most recently
from
3406d43 to
369add2
Compare
|
Thanks for the review. I think the remaining open comments are on the topic which of these alternatives we should choose, not disagreeing on the contents of this document, so I'll merge this now. The issue remains open, because we still have to pick an alternative 😄 |
See: #428