We did this inconsistently in PlainDate and ZonedDateTime, and not in the
other calendar-carrying types. Additionally, we don't have to create the
calendar explicitly in PlainDate.
This tests the normative change from
https://github.com/tc39/proposal-temporal/pull/2260
which achieved consensus in the July 2022 TC39 meeting.
The return value from a userland getOffsetNanosecondsFor method is no
longer allowed to be exactly one 24-hour day.
This adds tests that validate a user-callable getOffsetNanosecondsFor to
several APIs that didn't test this yet: ZonedDateTime.since/until, and
Calendar.era/eraYear.
In order for some tests to ensure that they are testing the right
exception, we need to make sure we are in the path where there are no
possible instants for a particular date-time. Override this method in some
tests.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2377 which reached
consensus at the September 2022 TC39 meeting.
It changes the order in which observable operations are performed on the
values passed to the ___fromFields methods of Calendar.
This adds an object, TemporalHelpers.ISO, which has methods that return
arrays of various ISO strings. The idea is to deduplicate more string
tests into methods on this object.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2287 which reached
consensus at the July 2022 TC39 meeting.
It adds tests that ensure that PlainTime strings which require a T
designator for disambiguation, are not disambiguated by adding a calendar
annotation.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2284 which reached
consensus at the July 2022 TC39 meeting.
It adds tests that ensure strings like HHMM-UU[TZ] and HHMMSS[TZ] do not
require a disambiguating T separator, even if HHMM-UU and HHMMSS would by
themselves.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2344 which reached
consensus at the July 2022 TC39 meeting.
It adds a test that catches a corner case in Duration.prototype.round().
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2269 which reached
consensus at the July 2022 TC39 meeting.
There was already a test for PlainDate for this topic, which needs to be
adjusted to accommodate the normative change. Tests for PlainDateTime and
ZonedDateTime did not yet exist, so add new ones based on the PlainDate
test.
There are already tests to reject negative day lengths, so we can simply
remove these other tests.
Also remove a misleading comment ("Test negative divisor"), because the
test following the comment actually uses a positive divisor.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2297 which reached
consensus at the July 2022 TC39 meeting.
Values given as the fractionalSecondDigits option are now truncated to
integers before they are compared to the allowable range.
The refISOYear argument in the Temporal.PlainMonthDay constructor can
cause a RangeError if it is outside the supported range for PlainDate.
This is part of a normative PR that reached consensus at the July 2022
TC39 plenary:
https://github.com/tc39/proposal-temporal/pull/2266
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
A normative change that reached consensus at the June 2022 TC39 meeting
was this small change to throw on an invalid value for the overflow option
in PlainDate.from() and PlainDateTime.from(), in the case of a fast-path
conversion.
See https://github.com/tc39/proposal-temporal/pull/2225
As of https://github.com/tc39/proposal-temporal/pull/2219 the arguments to
the calendar.mergeFields() methods should be null-prototype objects when
called from with() and toPlainDate() methods. This adds tests for that
behaviour.
As of https://github.com/tc39/proposal-temporal/pull/2219 the object
returned from the PrepareTemporalFields abstract operation should be a
null-prototype object. There are a number of places where this is
observable in one of the calendar's ...FromFields() methods. This adds
tests for this behaviour everywhere it is observable.
As of https://github.com/tc39/proposal-temporal/pull/2219 PlainYearMonth's
add() and subtract() methods should be calling the calendar's
yearMonthFromFields() method with a null-prototype object as the options
parameter, due to the change in
AddDurationToOrSubtractDurationFromPlainYearMonth. This adds a test for
this behaviour.
As of https://github.com/tc39/proposal-temporal/pull/2219 since() and
until() methods should be calling the calendar's dateUntil() method with a
null-prototype object as the options parameter, due to the change in
MergeLargestUnitOption. This adds a test for this behaviour.
This adds tests for a normative change which reached consensus in the June
2022 TC39 meeting, ensuring that the representable range of
Temporal.Instant is always the same regardless of which time zone offset
is used when converting from a string.
See: https://github.com/tc39/proposal-temporal/pull/2189
Philip Chimento
Frank Yung-Fong Tang
Philip Chimento
Aditi
André Bargull
Ms2ger