Normative: Allow annotations after YYYY-MM and MM-DD #2398
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2398 +/- ##
==========================================
+ Coverage 95.03% 95.10% +0.06%
==========================================
Files 20 20
Lines 10818 10829 +11
Branches 1925 1928 +3
==========================================
+ Hits 10281 10299 +18
+ Misses 503 495 -8
- Partials 34 35 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
Note that I've used the new "Annotated" naming from #2397 for the new grammar nonterminals, but I haven't renamed the old ones yet. This should probably be combined into one PR with #2394, #2395, and #2397, but I'm keeping it separate for now for ease of review. When combined with #2395, the check for "iso8601" in ParseISODateTime would need to check the ASCII-lowercase of the parsed calendar name. When combined with #2397, multiple annotations would need to be supported. |
ptomato
force-pushed
the
2379-annotation-yearmonth-monthday
branch
from
bff8261 to
73ed0d0
Compare
In keeping with the IXDTF format which extends the grammar of RFC 3339 with any number of annotations, we should allow annotations (time zone, calendar, and unknown after #2397 lands) after the short YYYY-MM PlainYearMonth and MM-DD PlainMonthDay forms. If we were to allow UTC offsets ±UU[:UU] alongside the time zone annotation, that would be ambiguous in one case: YYYY-MM-UU would be ambiguous with YYYY-MM-DD. This PR makes the following choices: - UTC offset is allowed after MM-DD - UTC offset is disallowed after YYYY-MM (even if it is positive, or contains a minute component, which would not be ambiguous) Other choices are certainly possible. Closes: #2379
ptomato
force-pushed
the
2379-annotation-yearmonth-monthday
branch
from
73ed0d0 to
03bff3f
Compare
Is this a bug in IXDTF? The grammar should not be ambiguous. |
IXDTF seems fine: Anything with less than a full date / full time isn't covered in RFC 3339, only in its ISO 8601 appendix. |
|
This just smells really fishy to me. I thought the point of IXDTF was to make it such that Temporal's datetime syntax was written down somewhere other than in ECMA-262. This is problematic for ICU4X because we're writing an IXDTF parser with the idea that it will be compliant with Temporal, but it sounds like doing so is not sufficient since Temporal has further extensions on top of IXDTF. Basically, we have RFC 3339, ISO-8601-1, ISO-8601-2, IXDTF, and Temporal that all have slightly different rules. |
|
I don't think that line of reasoning leads to a desirable outcome for anyone... RFC 3339's domain, same as IXDTF's, is the full-date full-time timestamp format, corresponding with Instant. We've always known that, and have in the past assumed that whatever annotation we standardize there is fine to carry over, with the necessary changes, to the Plain formats, because ISO 8601 allows omitting components. If we don't want to have annotations after YYYY-MM and MM-DD that's debatable (although we should have that discussion over at #2379, and preferably before the plenary.) |
|
Draft until presented at plenary (also depending on the outcome of the discussion at #2379) |
|
This needs updating to the new plan discussed in #2379. I'll close it for now. |
|
Updated to the new plan from #2379 (comment). |
|
Never mind, GitHub won't let me reopen the PR. A new PR is at #2428. |
As per the discussion in tc39/proposal-temporal#2379 (comment) and the PR tc39/proposal-temporal#2398, which is to be presented for consensus to TC39 in the upcoming plenary meeting, UTC offsets and the Z designator should be disallowed after any date-only strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to follow a time component. Z remains disallowed in any string being parsed into a Plain type. Annotations become allowed after any ISO string, even YYYY-MM and MM-DD where they were previously disallowed.
As per the discussion in tc39/proposal-temporal#2379 (comment) and the PR tc39/proposal-temporal#2398, which is to be presented for consensus to TC39 in the upcoming plenary meeting, UTC offsets and the Z designator should be disallowed after any date-only strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to follow a time component. Z remains disallowed in any string being parsed into a Plain type. Annotations become allowed after any ISO string, even YYYY-MM and MM-DD where they were previously disallowed.
As per the discussion in tc39/proposal-temporal#2379 (comment) and the PR tc39/proposal-temporal#2398, which is to be presented for consensus to TC39 in the upcoming plenary meeting, UTC offsets and the Z designator should be disallowed after any date-only strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to follow a time component. Z remains disallowed in any string being parsed into a Plain type. Annotations become allowed after any ISO string, even YYYY-MM and MM-DD where they were previously disallowed.
As per the discussion in tc39/proposal-temporal#2379 (comment) and the PR tc39/proposal-temporal#2398, which is to be presented for consensus to TC39 in the upcoming plenary meeting, UTC offsets and the Z designator should be disallowed after any date-only strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to follow a time component. Z remains disallowed in any string being parsed into a Plain type. Annotations become allowed after any ISO string, even YYYY-MM and MM-DD where they were previously disallowed.
In keeping with the IXDTF format which extends the grammar of RFC 3339
with any number of annotations, we should allow annotations (time zone,
calendar, and unknown after #2397 lands) after the short YYYY-MM
PlainYearMonth and MM-DD PlainMonthDay forms.
If we were to allow UTC offsets ±UU[:UU] alongside the time zone
annotation, that would be ambiguous in one case: YYYY-MM-UU would be
ambiguous with YYYY-MM-DD. This PR makes the following choices:
contains a minute component, which would not be ambiguous)
Other choices are certainly possible.
Closes: #2379