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/issues/1910 found a bug in an
indentation level of a line in the Temporal proposal, which affected the
outcome of the PreparePartialTemporalFields abstract operation. This adds
tests for all entry points that use that abstract operation, to make sure
the behaviour is correct: only defined properties are copied in with()
methods.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
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/pull/1907 was a bug that caused
negative Duration strings with fractional units to be rounded incorrectly.
Add tests that ensure the rounding mode is correct.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
These tests already existed for PlainDate. Copy them to the other types
(and use the constructor instead of from() in order to be as simple as
possible)
Some of these (in PlainDate) had already been rewritten to test more
invalid strings that are otherwise valid units. This commit takes these
improvements and brings them to all of the similar tests for other types'
since() and until() methods.
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.
This requires a few adjustments of time zone names and offsets in some
places. The only named time zone that is required to be supported by an
implementation not supporting ECMA-402 is "UTC".
Nails down intended behavior of `PlainDate` and
`PlainDateTime`'s `since` that is already true in the
polyfill but which was specified in a buggy way (and hence
potentially not true in an implementation of Temporal).
Add similar tests for Instant, PlainTime, PlainYearMonth, and
ZonedDateTime.
Reference:
https://github.com/tc39/proposal-temporal/pull/1881
Move part of the test of toLocaleString which depends on
15 Amendments to the ECMAScript® 2021 Internationalization API Specification
to intl402. Keep behavior specified in earlier chapters in built-ins
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/1875
For convenience, adds some functions to TemporalHelpers to assert that two
Temporal objects are equal, for Duration, Instant, PlainDateTime,
PlainTime, and ZonedDateTime.
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
Justin Grant
Frank Tang