For completeness, as we are doing in newer brand checking tests such as
those of Temporal, call these getters with a function object and a bigint
as the receiver.
Suggested in https://github.com/tc39/test262/pull/3614/files#r929662337
Now that we have a staging directory, we can add the old-style tests from
proposal-temporal and avoid having to sync PRs across two repositories
when we convert them to test262 style.
Ms2ger wrote a script to convert them to be executable with the test262
harness, and this is the result of running that script on the remaining
Temporal.Instant tests in proposal-temporal.
More tests of other Temporal types to follow.
The intention of this test is to ensure that all built-in properties of
the global object are also exposed on the ShadowRealm's global object,
without penalizing implementations that don't have all of them
implemented.
Notably, SharedArrayBuffer may still not be (re-)enabled in all
circumstances.
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 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
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.
Everywhere an ISO string is accepted in Temporal, a seconds value of :60
should always be coerced to :59, because of how leap seconds are handled
in ISO strings.
In property bags, a 'seconds: 60' property is not subject to that rule: it
should be handled according to the overflow option if there is one.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
Each from() method except Calendar and TimeZone should test that when you
pass an instance of that type, the return value is a clone of that
instance, and a distinct object.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
In order to test the referenceISODay of a PlainYearMonth we add an
argument to TemporalHelpers.assertPlainYearMonth.
In Date.parse() and new Date(), representations of the year 0 as -000000
must not be accepted. In the case of Date.parse(), they should yield NaN,
and in the case of new Date(), they should yield an invalid Date object,
whose valueOf() is NaN.
These tests cover, for every API entry point where a Temporal object is
expected, what happens when a value of a different type is passed in that
can't be converted.
Most entry points can convert a string to the expected Temporal type, and
will do ToString on any non-Object argument, and throw RangeError if the
result isn't a string that's convertible to that Temporal type. ToString
will throw TypeError on a Symbol.
Most entry points also take a property bag, and will throw TypeError if
the property bag doesn't have the required properties.
We also have to test for TimeZone and Calendar what happens if the wrong
type is provided as the value of a 'timeZone' or 'calendar' property in
another property bag, up to one level of nested properties.
Adds tests for conversion of a Number whose corresponding toString() value
is a valid ISO string. For some Temporal types this is possible, with a
number like 20220418.
Especially for Temporal.Calendar, we have to take into account the case
where the number is provided as the value for the 'calendar' property in a
property bag, and the case of up to one level of nested property bag as
well.
Regularizes and expands existing tests for this case.
The test for a TimeZone created from an ISO string with multiple offsets
was missing from the Temporal.ZonedDateTime constructor, whereas it was
present for several other APIs. Add it.
We already had similar tests to these for other methods, such as
Temporal.PlainTime.prototype.equals(). since() and until() should have
these tests too.
Update assertion messages in all of the existing tests as well, as per
Ms2ger's review comment.
An object may be given in any context where a Temporal.Instant is expected
(see ToTemporalInstant). There is no conversion from a property bag to an
Instant, unlike with other Temporal types. Instead the object is converted
to a string, and if its toString() method yields a valid ISO string, the
conversion succeeds. (An object with the default Object.prototype.toString
will not.)
We should make sure that we are providing the correct arguments to these
methods even if they are supposed to throw; they should throw for the
reason we expect, and not because we provided the wrong arguments.
Philip Chimento
Richard Gibson
Aditi
Ms2ger
Linus Groh
Yusuke Suzuki
Kevin Gibbons
André Bargull
Mathias Bynens
Zirak
Frank Yung-Fong Tang
snek
Romulo Cintra
Romulo Cintra
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
Jesse Alama
Jesse Alama