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

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

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

As of tc39/proposal-temporal#2397 which reached
consensus in the August 2022 TC39 meeting, a date-time + Z with no bracket
annotation is no longer accepted as a relativeTo parameter; either the Z
should be removed or a bracket annotation should be added.

This requires adjusting a few existing tests, but doesn't require any new
ones.

See tc39/proposal-temporal#2397
Adds tests for ISO strings with named and numeric offset time zone
annotations, with and without the critical flag, with various combinations
of Z and offset in front of the annotation.

See tc39/proposal-temporal#2397
Adds tests for ISO strings with calendar annotations, with and without the
critical flag, and also a check that the second calendar annotation is
disregarded, as per the IETF draft.

See tc39/proposal-temporal#2397
Adds tests for ISO strings with unrecognized annotations, (i.e., neither
time zone nor calendar), in various combinations with recognized
annotations.

See tc39/proposal-temporal#2397
Adds tests for ISO strings with unrecognized annotations with the critical
flag. These strings should all be rejected.

See tc39/proposal-temporal#2397
Adds tests for ISO strings with more than one time zone annotation. These
are not syntactically correct according to the grammar and should be
rejected.

See tc39/proposal-temporal#2397
This normative change adds a new accepted value for the calendarName
option in various toString() methods.

See tc39/proposal-temporal#2397
This normative change adds a new accepted value for the timeZoneName
option in ZonedDateTime.prototype.toString().

As of tc39/proposal-temporal#2397 which reached
consensus in the August 2022 TC39 meeting, a date-time + Z with no bracket
annotation is no longer accepted as a relativeTo parameter; either the Z
should be removed or a bracket annotation should be added.

This requires adjusting a few existing tests, but doesn't require any new
ones.

See tc39/proposal-temporal#2397
Adds tests for ISO strings with named and numeric offset time zone
annotations, with and without the critical flag, with various combinations
of Z and offset in front of the annotation.

See tc39/proposal-temporal#2397
Adds tests for ISO strings with calendar annotations, with and without the
critical flag, and also a check that the second calendar annotation is
disregarded, as per the IETF draft.

https://bugs.webkit.org/show_bug.cgi?id=277942

Reviewed by Yusuke Suzuki.

RFC 3339[1] and RFC 9557[2] allows that bracketed timezone annotations include a critical flag(!)[3].
It indicate that the parsing should be rejected if there is a conflict between the offset and the
timezone annotation.

Temporal API has added this feature into the spec[4]. While the critical flag does not affect the
behavior of Temporal, parsing must still succeed.

Currently, JSC throws an error when creating a Temporal object from a string that includes a
critical flag.

This patch changes to allow creating Temporal objects from strings that include a critical flag.

[1]: https://www.rfc-editor.org/rfc/rfc3339
[2]: https://www.rfc-editor.org/rfc/rfc9557
[3]: https://www.rfc-editor.org/rfc/rfc9557.html#name-inconsistent-time-offset-an
[4]: tc39/proposal-temporal#2397

* JSTests/stress/temporal-instant-tz-critical-flags.js: Added.
* JSTests/stress/temporal-plaindate-tz-critical-flags.js: Added.
* JSTests/stress/temporal-plaindatetime-tz-critical-flags.js: Added.
* JSTests/stress/temporal-plaintime-tz-critical-flags.js: Added.
* JSTests/test262/expectations.yaml:
* Source/JavaScriptCore/runtime/ISO8601.cpp:
(JSC::ISO8601::parseTimeZoneBracketedAnnotation):

Canonical link: https://commits.webkit.org/282211@main

https://bugs.webkit.org/show_bug.cgi?id=223166

Reviewed by NOBODY (OOPS!).

Implement critical flag, multiple calendar annotations,
and unknown annotations so that the remaining Temporal.Instant.From
test262 tests pass (except for ones using ZonedDateTime)
See tc39/proposal-temporal#2397 for the origin
of these changes.

* JSTests/stress/temporal-instant.js:
* JSTests/test262/config.yaml:
* Source/JavaScriptCore/runtime/ISO8601.cpp:
(JSC::ISO8601::canBeCalendar):
(JSC::ISO8601::parseOneCalendar):
(JSC::ISO8601::parseCalendar):
(JSC::ISO8601::parseCalendarTime):
(JSC::ISO8601::parseCalendarDateTime):
(JSC::ISO8601::parseInstant):
* Source/JavaScriptCore/runtime/ISO8601.h:
* Source/JavaScriptCore/runtime/TemporalPlainDate.cpp:
(JSC::TemporalPlainDate::from):
* Source/JavaScriptCore/runtime/TemporalPlainDateTime.cpp:
(JSC::TemporalPlainDateTime::from):
* Source/JavaScriptCore/runtime/TemporalPlainTime.cpp:
(JSC::TemporalPlainTime::from):

https://bugs.webkit.org/show_bug.cgi?id=223166

Reviewed by Justin Michaud and Sosuke Suzuki.

This does not change anything currently, but is groundwork for
implementing a normative change to the Temporal proposal:
tc39/proposal-temporal#2397
It changes parseCalendar() to handle unknown annotation keys and known
annotation keys with the `!` critical flag. (Although those are still
disallowed by canBeCalendar() at this time, I will send a follow-up PR
for that.)

Note this code was already submitted as part of
WebKit#36361 which I'm trying to split up
into smaller, more easily reviewable parts.

* Source/JavaScriptCore/runtime/ISO8601.cpp:
(JSC::ISO8601::parseCalendar):

Canonical link: https://commits.webkit.org/293522@main

https://bugs.webkit.org/show_bug.cgi?id=223166

Reviewed by Yusuke Suzuki.

This is part of a normative change to the Temporal proposal:
tc39/proposal-temporal#2397
It adds support for the `!` critical flag to calendar annotations in
parsed strings. The flag is ignored in all normal cases, but we still
store it as a boolean in CalendarRecord, because when we start handling
unknown annotation keys, we'll need to treat those differently depending
on whether they were flagged or not.

Note this code was already submitted as part of
WebKit#36361 which I'm trying to split up
into smaller, more easily reviewable parts.

* JSTests/stress/temporal-instant.js:
* Source/JavaScriptCore/runtime/ISO8601.cpp:
(JSC::ISO8601::canBeCalendar):
(JSC::ISO8601::parseCalendar):
* Source/JavaScriptCore/runtime/ISO8601.h:

Canonical link: https://commits.webkit.org/293612@main

https://bugs.webkit.org/show_bug.cgi?id=223166

Reviewed by Yusuke Suzuki.

This is part of a normative change to the Temporal proposal:
tc39/proposal-temporal#2397
This change stops assuming that all calendar annotations have the `u-ca`
key, and instead parses the key according to the grammar in the spec
text. Unknown annotations are ignored unless they have the `!` flag, in
which case they cause the string to throw.

* JSTests/stress/temporal-instant.js:
* Source/JavaScriptCore/runtime/ISO8601.cpp:
(JSC::ISO8601::canBeCalendar):
(JSC::ISO8601::parseCalendar):
* Source/JavaScriptCore/runtime/ISO8601.h:

Canonical link: https://commits.webkit.org/293705@main

https://bugs.webkit.org/show_bug.cgi?id=223166

Reviewed by Justin Michaud.

This is part of a normative change to the Temporal proposal:
tc39/proposal-temporal#2397
This change allows parsing multiple annotations in Temporal strings. If
there are multiple `u-ca` calendar annotations, the first one is used.
But if there are multiple calendars and any have the `!` flag, the
string is rejected because that's inconsistent.

This makes a lot of test262 tests newly pass and they can be removed
from the skip list. Some other tests under the same heading still fail
because PlainDate and PlainDateTime don't yet support calendars, so
recategorize them under the "Depends on calendar support" heading.

* JSTests/stress/temporal-instant.js:
* JSTests/test262/config.yaml:
* Source/JavaScriptCore/runtime/ISO8601.cpp:
(JSC::ISO8601::parseOneCalendar):
(JSC::ISO8601::parseCalendar):
(JSC::ISO8601::parseCalendarTime):
(JSC::ISO8601::parseCalendarDateTime):

Canonical link: https://commits.webkit.org/293742@main