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.
Adapt to the following changes in CLDR 42 in Node 19:
- Some spaces in formats replaced by other whitespace unicode characters
- German format changes, which may be bugs (see
https://unicode-org.atlassian.net/browse/CLDR-16243)
This commit makes affected tests more resilient to Intl.DTF output
changes between Node versions.
A good idea for a future PR would be to change these tests to rely less
on CLDR formats while still testing that Temporal and Intl are behaving
as expected.
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.
This adds order-of-operations tests that cover all of the Temporal entry
points that accept options bags, that were not already covered. We'll be
using these tests in the future to verify
https://github.com/tc39/proposal-temporal/issues/2254
However, the tests in this commit reflect the current state of the
proposal, not the potential normative change.
Some of the existing order-of-operations tests didn't observe the calendar
operations. Add a TemporalHelpers.calendarObserver() calendar to the
invocations of these methods in the order-of-operations tests.
Some of the existing order-of-operations tests didn't pass an options bag:
primarily from(), with(), add() and subtract(). (since() and until() were
covered in a previous commit.)
Add a TemporalHelpers.propertyBagObserver() options bag to the invocations
of these methods in the order-of-operations tests.
The `relativeTo` parameter in an options bag may be undefined, a PlainDate
instance, or a ZonedDateTime instance. Each of these three possibilities
causes a different set of observable operations, which we can test in our
existing order-of-operations tests.
There are additional observable operations that occur when providing an
`offset` property in a relativeTo or ZonedDateTime property bag. We can
test these in our existing order-of-operations tests.
%TypedArray%.prototype.map's iteration count does not change even though the source view is resized during the iteration.
And since result is just returning index, then result array should be [0, 1, 2].
Use the new collections of strings in TemporalHelpers.ISO to add more
tests for ISO strings in API entry points that convert an ISO string to
Temporal.PlainYearMonth or Temporal.PlainMonthDay.
The idea is to deduplicate more string tests into methods on this object,
that return collections of valid and invalid strings. This adds
collections of valid and invalid PlainYearMonth and PlainMonthDay strings.
