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
Prior to this commit, two tests for specific early errors also included
syntactically invalid `const` declarations. Implementations which
produced the expected syntax error due to these invalid declarations
would pass the tests regardless of whether they produced the early
errors that the tests were written to verify.
Correct the `const` declarations so that the tests verify the parsing
rule that they were designed to verify.
The test as originally specified fails in all compatible parsers, but for the wrong reason. Below is an excerpt from V8, but all parser I tested behave the same:
```js
for (const x; false; ) {
^
SyntaxError: Missing initializer in const declaration
```
After the change the error is the assumed:
```js
var x;
^
SyntaxError: Identifier 'x' has already been declared
```
This adds tests to all entry points where an ISO string is converted to a
Temporal.Instant. The tests exercise various invalid ISO strings to make
sure that they throw a RangeError.
This adds tests for https://github.com/tc39/proposal-temporal/pull/2203
which was a normative change that reached consensus in the June 2022 TC39
plenary meeting.
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
The options-invalid.js tests were also covered by options-wrong-type.js.
The tests for add/subtract without an options argument were also covered by options-undefined.js.
ISO strings may separate the time from the date with a case-insensitive T,
or a space. This adds tests to all entry points that take ISO strings, to
ensure that they accept an uppercase T, lowercase T, or space as the time
separator.
These tests are based on the one test for Temporal.PlainDateTime.from that
was already present.
I suggested in #3517 that these lines should be removed but didn't realize
they must be present because TemporalHelpers.assertPlainDateTime is going
to check the 'era' and 'eraYear' properties.
This adds coverage for the situation where we get a different answer from
Temporal.Duration.compare depending on whether relativeTo resolves to a
PlainDate or ZonedDateTime.
See discussion in
https://github.com/tc39/test262/pull/3505#discussion_r859994610
Some of these strings wouldn't have been valid even with a valid year in
them (e.g. strings ending in +01:00[UTC]) so fix up the strings that we
test. While touching these tests, I took the opportunity to regularize
them, and add some missing ones for ISO strings that convert to Calendar
and TimeZone.
Be consistent about creating Temporal objects for use in tests with direct
constructor calls, instead of relying on string coercions. This reduces
coupling in the tests.
Mathias Bynens
Philip Chimento
André Bargull
Zirak
Aditi
Frank Yung-Fong Tang
snek
Romulo Cintra
Romulo Cintra
Ms2ger
Yusuke Suzuki
dnalborczyk
legendecas
Youssef Soliman
Mike Pennisi
Ross Kirsling
Dmitriy Kubyshkin
Huáng Jùnliàng
Iban Eguia Moraza
Keith Miller
Jordan Harband
Shane F. Carr