This adds several tests for values that should be produced by the time
zone database and should not be subject to change in the future. This
tests basic functionality of TimeZone.getPlainDateTimeFor with an IANA
time zone database.
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.
Aside from the ones that were already tested in etc-timezones.js, this
adds a test for other IANA legacy names.
Previously these were supported in the TimeZone constructor, but not in
from().
See https://github.com/tc39/proposal-temporal/pull/2292 which is a
normative change that achieved consensus at the July 2022 TC39 meeting.
The Etc/GMT±... time zones should be accepted in from() as well as the
TimeZone constructor. Previously this was not the case for +0 and -0 due
to those being IANA legacy names.
This basically copies the existing test file for the TimeZone constructor,
and performs the same tests for TimeZone.from().
See https://github.com/tc39/proposal-temporal/pull/2292 which is a
normative change that achieved consensus at the July 2022 TC39 meeting.
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
The existing test passed an object for a `this` value. This commit checks that
primitive values are returned verbatim, without any conversion.
Resolve#3489.
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
Aditi
André Bargull
Mathias Bynens
Zirak
Frank Yung-Fong Tang
snek
Romulo Cintra
Romulo Cintra
Ms2ger
Yusuke Suzuki
dnalborczyk
legendecas
Youssef Soliman