Tests for the process of calculating the reference ISO day for
Temporal.PlainYearMonth and the reference ISO year for
Temporal.PlainMonthDay.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2475
In https://github.com/tc39/proposal-temporal/pull/2474, which achieved
consensus at the TC39 plenary meeting of 2023-01-31, the implementation-
defined steps for Temporal.Calendar.prototype.mergeFields had their
language tightened, to better specify what implementations must do.
This adds tests covering the new spec language, and moves one related test
out of staging.
This is a process allowing contributors to submit well-motivated
proposals to improve test262 using an RFC (Request For Commments)
process which is adapted from a similar process in the Rust community.
In since() and until() methods, we copy the options object with
CopyDataProperties. Previously, its properties could be read in more than
one place (the method itself, and the calendar method), triggering user
code each time. Now, we pass around null-prototype objects with only data
properties.
See https://github.com/tc39/proposal-temporal/pull/2447
Previously in a few cases (calendar units in Duration) the value for the
roundingIncrement option had no upper limit, other than having to be
finite. These tests cover a normative change limiting it to 1e9.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2480
The with() methods, as well as PlainYearMonth's since() and until(), were
adjusted to read the receiver's fields before the fields of any objects
provided as arguments. This change is observable, so affects several tests
that test the observed order of operations.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2478
I used a script to "unroll" some of the calls to
TemporalHelpers.checkToTemporalCalendarFastPath(), and rewrite it slightly
not to use a specific Calendar instance. This is in preparation for a
future refactor, but also allows testing the PlainTime path which was not
previously covered.
(I didn't unroll all the calls and remove the helper yet, because the
remaining calls have custom assertions that I haven't gotten the script to
work with yet. For the same reason, I didn't yet convert these to use the
test generation facility. These will follow in a future PR.)
For each entry point where a string calendar name is accepted, we should
have a test that ensures the calendar name is case-insensitive. These
tests existed but several were incomplete as they didn't take nested
properties into account, and several entry points were missing this test.
Fix a minor copy-paste issue with double semicolons.
I overlooked the fact that passing an imported module object to $DONE will
correctly fail the test.
I still think this way of writing the test is unclear, though.
This proposes a `harness/asyncHelpers.js` file with two helpers in it,
`asyncTest()` and `assert.throwsAsync()`. See the RFC for further
motivation and details.
Note the draft RFC process in https://github.com/tc39/test262/pull/3525.
My idea for this pull request is that besides being an RFC in its own
right, we use it as a test case for the process. That is, we follow the
draft RFC process and hopefully either validate it, or surface changes
that need to be made, after which we can land the RFC process in our
documentation.
Following up on #3751 and #3762, this commit makes a few tests
work on both CLDR 42 and CLDR 41. Previously these tests were
tied to a specific CLDR 42 format.
