Here's a test I should have included in #3395. It's allowed to replace the
"T" in the middle of an ISO string with a space, but not when the "T" is a
time designator prefix. This assertion ensures that implementations make
this distinction correctly.
https://github.com/tc39/proposal-temporal/pull/1952 added support for time
designator prefixes in PlainTime strings. This adds three tests to all
entry points that convert an ISO string to a PlainTime:
- no-implicit-midnight: ISO strings with only a date and no time are no
longer accepted. Previously they were implicitly interpreted as 00:00.
- with-time-designator: Tests that various forms of string with time
designator are correctly parsed.
- time-designator-required-for-disambiguation: Tests various cases where
a string without a time designator is ambiguous and therefore the time
designator is required, as well as various cases that implementations
might assume are ambiguous but in fact are not.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
https://github.com/tc39/proposal-temporal/issues/1753 records the
consensus reached at the October 2021 TC39 meeting to disallow "-000000"
as an extended year, both in Date.parse and Temporal. This adds tests for
the Temporal part of that.
Unfortunately, in #3304 I made a last-minute mistake when I added the
uncallable value to the assertion message, and neglected to test it;
Symbols can't be converted to strings like that, so these tests would
fail. This fixes the assertion messages.
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1829
In a previous version of the specification, there was a fallback to the
intrinsic getOffsetNanosecondsFor when it was undefined.
Philip Chimento
Ms2ger
Jesse Alama
Philip Chimento