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.
Note that this test currently unintentionally passes, because a
TypeError is thrown for failing to convert the undefined returned from
the getter to a BigInt. But since this test was intended to test
detaching, it's no longer valid and should still be removed.
See https://github.com/tc39/test262/pull/3465#issuecomment-1098388916
The round() and toString() methods of Temporal.Instant, PlainDateTime, and
ZonedDateTime can round up or down. However, the instance must not be
treated as "negative" even when the time is before 1 BCE (years are
negative) or before the Unix epoch (epoch nanoseconds are negative). That
is, rounding down is always towards the Big Bang, and rounding up is
always away from it. Add tests that verify this.
This takes the tests of the rounding functionality of
Temporal.PlainTime.p.toString() and adds similar tests covering the
equivalent functionality to Duration, Instant, PlainDateTime, and
ZonedDateTime: all the types that have rounding and precision controls
for how they output their subsecond values.
It also takes the opportunity to improve the existing PlainTime tests:
- fractionalseconddigits-auto.js: More descriptive variable names. Added
assertion messages.
- fractionalseconddigits-number.js: Ditto.
- rounding-cross-midnight.js: Use constructor directly to remove coupling
with from().
- roundingmode-*.js: Add additional tests for specifying the precision
using fractionalSecondDigits.
- smallestunit-fractionalseconddigits.js: Add assertion messages.
This consolidates the few existing tests for options bags in Temporal
being of the wrong type, and adds them for every entry point in Temporal
that accepts an options bag.
These are mostly identical tests, but there is a variation for methods
like round() where either an options bag or string is accepted.
Add a consistent set of invalid strings for all of the
smallestunit-invalid-string.js and largestunit-invalid-string.js tests:
- "era" and "eraYear" in singular and plural
- all of the units that are disallowed for that particular method call, in
singular and plural
- an allowed unit with \0 at the end
- an allowed unit with an "i" replaced by a dotless i
- an allowed unit but with all-caps
- an unrelated string.
Of the toString() methods that have options for printing a time with
seconds and fractional seconds, PlainTime seems to have the most
comprehensive set of tests. Bring all the others (Duration, Instant,
PlainDateTime, and ZonedDateTime) in sync with PlainTime, and edit the
PlainTime ones where necessary to include improvements from the others.
Tests:
- fractionalseconddigits-invalid-string.js: copy and expand on
PlainTime's more comprehensive set of invalid strings. Add assertion
message. Fix front matter.
- fractionalseconddigits-non-integer.js: Fix front matter.
- fractionalseconddigits-out-of-range.js: make sure infinity is tested.
Add assertion messages. Fix front matter.
- fractionalseconddigits-undefined.js: copy PlainTime's more
comprehensive test with whole minutes, whole seconds, and subseconds.
Copy PlainTime's test of an empty function object. Add more
descriptive variable names and assertion messages. Fix front matter.
- fractionalseconddigits-wrong-type.js: inline and delete TemporalHelper
used here; it was only good for this test anyway. Improve assertion
messages.
- smallestunit-valid-units.js: copy PlainTime's test with a second value
with zero seconds even. Refactor repetitive tests into a loop. Copy
the invalid unit "era" from the Instant test. Add assertion messages.
A prior version of ECMA262 described invalid mathematical operations
with infinite values [1]. Update the test metadata to reflect the
corrected specification text, and add two assertions for the obsolete
conditions.
[1] ".bind on a function with infinite length has imprecise spec and
engine divergences"
https://github.com/tc39/ecma262/issues/2170
As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
https://github.com/tc39/proposal-temporal/pull/2003 is a normative change
that reached consensus at the March 2022 TC39 plenary meeting. This adds
tests that verify the new spec text is implemented correctly, performing
arithmetic on a PlainYearMonth instance that would previously have thrown
an error if it was implemented as written.
https://github.com/tc39/proposal-temporal/pull/2090 is a normative change
that reached consensus at the March 2022 TC39 plenary meeting. This adds
tests that verify the change made to the formatting of years between 0 and
999 inclusive in all toString and toJSON methods of Temporal types that
can output an ISO year number in their return value.
(Philip, March 2022: This was originally Frank's PR #3057. I did some
reformatting, removed duplicate tests, addressed the review comments that
I left the first time around, and added some cases that I felt were not
yet complete.)
(Philip, March 2022: This was originally Frank's PR #3060. I did some
reformatting, removed a test that didn't exercise the whole feature, and
combined some duplicate tests with some existing tests.)
Where possible, observable calls originating from within Temporal, that
require an options argument, should pass `undefined` as that options
argument, rather than `{}` or `Object.create(null)`.
See tc39/proposal-temporal#1685.
I made a mistake with one of the signs in one of the time zones that we
use for verifying DST handling. Luckily this didn't affect any previously
existing tests, but it affected some new tests that I'm going to add in
the next commit.
How do I know that _this_ arithmetic is correct? I feel reasonably
confident with the added test.
These tests check API entry points that convert strings to
Temporal.PlainDate, with a list of various strings that are all not valid
for that context according to ISO 8601.
I'd like to add basic functionality tests for string arguments, and these
tests are testing something more specific: that a Get of the "overflow"
property on the passed-in options object is observable. Rename
accordingly.
* Create a Temporal.PlainDateTime with all arguments supplied.
Migrates some tests that currently exist in the
proposal-temporal repo.
* Check all data in Temporal.PlainDateTimes, variously constructed
Enrich existing tests to check all basic data in the
instance of `Temporal.PlainDateTime`, not just a single
field.
These additional checks were motivated by the migration of
existing Demitasse tests in the proposal-temporal repo to
test262. The Demitasse tests check more than a single
field.
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.
There were three things wrong with the 'and', 'or', and 'nullish' tests
that I added as part of #2940:
1. They were in the wrong folder (should be
expressions/logical-assignment, not expressions/compound-assignment)
2. The tests for ||= and ??= on readonly accessor properties were
incorrect. These assignments would short-circuit if the getter
returned 1 as it previously did, so PutValue would not throw.
3. The tests for ||= and ??= on private methods were invalid, as a
method always evaluates to true in a boolean context, and is not
nullish, so these would always short-circuit.
I've removed the invalid private method cases, fixed the readonly
accessor cases, and added new templates to test the short-circuit
behaviour as well as the non-short-circuit behaviour.
Closes: #3413
This tests compound assignment, with each compound assignment operator,
to each kind of private reference (private field, private accessor
property with getter and setter, private accessor property with only
getter, and private method). The latter two cannot be assigned to and
therefore throw.
Closes: #2940
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/1956 clarified that the
fractionalSecondDigits and smallestUnit options to
Temporal.Duration.p.toString() specified the exact number of digits after
the decimal point, no more and no less.
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.
A follow up to the previous commit, this rewrites some tests that relied
on the lack of brand checks for certain Temporal.TimeZone methods.
https://github.com/tc39/proposal-temporal/pull/1693 added brand checks to
these methods.
We can no longer use a plain object time zone or even a Proxy with a real
branded Temporal.TimeZone object as its handler to do these tests, so we
instead create an instance of Temporal.TimeZone and define own accessor
properties on it in order to test the observable property accesses that we
need to see according to the spec text.
This requires an improvement to TemporalHelpers.observeProperty() in order
to be able to log property accesses to Symbol-valued properties.
https://github.com/tc39/proposal-temporal/pull/1693 added checks for the
receiver of certain Temporal.Calendar and Temporal.TimeZone methods. Add
branding tests for these methods, similar to the already existing branding
tests.
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)
I forgot to add these to PlainDate, testing what happens when we pass
undefined as the value for the largestUnit option. Similar tests already
exist for the other types.
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.
https://github.com/tc39/proposal-temporal/pull/1893 was a bug that caused
the 'offset' property to be ignored in ZonedDateTime property bags. Add
tests that ensure it is not ignored.
This was a normative change that achieved consensus at the October 2021
TC39 meeting.
https://github.com/tc39/proposal-temporal/pull/1780 fixed a typo in the
UnbalanceDurationRelative abstract operation, which should affect the
entry points tested here.
This was a normative change that achieved consensus at the October 2021
TC39 meeting.
There were two cases where tests in intl402/ had some duplication of tests
that are in built-ins/ as well. Remove this duplication, and restrict the
intl402/ tests to testing things that can't be tested on all hosts.
Mathias Bynens
Ms2ger
Aditi
Yusuke Suzuki
dnalborczyk
Philip Chimento
Romulo Cintra
legendecas
Youssef Soliman
Mike Pennisi
Frank Yung-Fong Tang
Ross Kirsling
Dmitriy Kubyshkin
André Bargull
Huáng Jùnliàng
Iban Eguia Moraza
Romulo Cintra
Keith Miller
Jordan Harband
Shane F. Carr
Jesse Alama
Jesse Alama
Shu-yu Guo
Jesse Alama
rwaldron
Richard Gibson
Frank Yung-Fong Tang
Philip Chimento
Alexey Shvayka
Linus Groh
Romulo Cintra
James Wright