This is the replacement of the old API with the new API, .timeZoneId and
.getTimeZone(). Semantics will be corrected in the following commit.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
Compare semantics for custom calendars that _don't_ extend
Temporal.Calendar (and therefore don't have the internal slot) use the
value of the .id property, instead of calling toString().
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
In several tests involving custom calendars, we need to change the
implementation of dateFromFields/monthDayFromFields/yearMonthFromFields so
that the returned object gets the receiver as its calendar after chaining
up to the builtin implementation.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
Has several effects on existing tests:
- Remove PlainTime from various tests that extract a Temporal.Calendar
instance from another Temporal object.
- Remove Temporal.PlainTime.prototype.calendar property.
- Remove calendar property from object returned from
Temporal.PlainTime.prototype.getISOFields().
- Ignore calendar annotation when converting ISO string to PlainTime.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
This contains a few more tests for Array.fromAsync, in addition to what
has already been merged and what is under review at #3791.
This covers the following items from the testing plan at #3725:
- Success cases
- Creates promise
- Create new array/arraylike in promise (with length = length property)
- Input
- Invalid input values
- nonconforming object (arraylike without length, missing keys)
- Covered by polyfill tests
- Result promise rejects if length access fails (non-iterable input)
- Unaffected by globalThis.Symbol mutation (non-iterable)
- this-value
- this-value is a constructor
- this-value is not a constructor
- If this is a constructor, and items doesn't have a Symbol.iterator,
returns a new instance of this
- Iterator closed when property creation on this fails
- Returned promise rejects when ^
- Other tests
- Error is thrown for all CreateDataProperty fails
- Non-writable properties are overwritten by CreateDataProperty
- Input with missing values
Co-authored-by: Ms2ger <Ms2ger@igalia.com>
This adds copies of the tests added in the previous commit, to the
respective BigInt folders, editing them to use the testBigIntTypedArray
helper instead of the testTypedArray helper.
See: #3723
- normal case with synchronous and asynchronous mapfn
- a non-callable value is passed as mapfn
- behaviour of various values of thisArg in strict and sloppy mode
- mapfn result is awaited once per iteration
- iterator is closed when mapfn throws
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.
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.
Here are some of the standard tests for property metadata of the
Array.fromAsync property and for the built-in function object. These don't
require doing anything asynchronously, so can be considered separately
from the Async Helpers RFC.
* Reject exceptional input to `isConstructor`
Prior to this commit, the `isConstructor` harness function would return
`false` when invoked with a value that lacked a [[Call]] internal
method. While it's true that such values are not constructors, there are
no tests which benefit from using `isConstructor` to make such an
assertion.
Extend `isConstructor` to throw an error when invoked with a
non-function object. Update a test which was misleadingly invoking the
function with the value `undefined`.
* fixup! Reject exceptional input to `isConstructor`
This contains tests for the normative PR
https://github.com/tc39/proposal-temporal/pull/2437, which is to be
presented for consensus to TC39 in the upcoming plenary meeting. That PR
changes the observable order of property accesses to be alphabetical where
possible.
1. String.prototype.toWellFormed's name is "toWellFormed".
2. "asserts" does not exist in the test harness, and "assert.throws"
expects the error type first.
This reconciles changes made in two normative PRs to the Temporal proposal
which each had their own separate PRs for tests. The yearOfWeek tests were
written before the changes to the ISO 8601 grammar which disallowed the
YYYY-MM-DD+UU format. This brings the yearOfWeek tests in line with the
tests for the other calendar methods.
While we're at it, use assert() instead of assert.sameValue() for brevity,
if we are not specifically testing that the return value of hasOwnProperty
is the value true or false; and add more informative assertion messages to
help with debugging.
In some cases, the Object.hasOwnProperty.call could be replaced with
verifyProperty(), if the property descriptor was also being verified at
the same time.
This fixes some tests that were faulty to begin with: a common mistake was
Object.hasOwnProperty(obj, prop) which is probably going to return false
when that's not what you want.
The only instances left of `Object.hasOwnProperty` are one regression test
in implementation-contributed which I can't tell if it was intentionally
needed to trigger the regression, and a few instances of
`Object.hasOwnProperty('prototype')` which would defeat the purpose to
convert into `Object.prototype.hasOwnProperty.call(Object, 'prototype')`
form.
Closes: #3524
As per the discussion in
https://github.com/tc39/proposal-temporal/issues/2379#issuecomment-1248557100
and the PR https://github.com/tc39/proposal-temporal/pull/2398, which is
to be presented for consensus to TC39 in the upcoming plenary meeting, UTC
offsets and the Z designator should be disallowed after any date-only
strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to
follow a time component. Z remains disallowed in any string being parsed
into a Plain type.
Annotations become allowed after any ISO string, even YYYY-MM and MM-DD
where they were previously disallowed.
To be presented for consensus in the November/December TC39 meeting. This
adds tests for a 'yearOfWeek' getter to PlainDate, PlainDateTime, and
ZonedDateTime, for use alongside 'weekOfYear', and tests for a
corresponding method to Calendar.
The tests are basically the existing tests of 'weekOfYear' adapted.
Temporal issue: https://github.com/tc39/proposal-temporal/issues/2405
This contains tests for the normative PR
https://github.com/tc39/proposal-temporal/pull/2433, which is to be
presented for consensus to TC39 in the upcoming plenary meeting. That PR
changes ToTemporalCalendar to throw when it encounters a Temporal.TimeZone
instance, and ToTemporalTimeZone to throw when it encounters a
Temporal.Calendar instance.
We already have a similar test covering TimeZone.id that ensures toString
is not called. We did not have this coverage yet for Calendar.id, so adapt
the TimeZone test for Calendar.
