I noticed a small test hole in codecov: we weren't testing
Temporal.Instant parsing with trailing zeroes in the offset.
I also didn't see fractional offset testing, so added that too.
Codecov showed that PlainTime strings like "09:00:00Z[UTC]" or
"09:00:00Z" were not being tested. This commit fills that gap.
It'd probably be good to make similar changes for other Plain* types,
but Codecov didn't complain about them so they may be covered
via other tests so it was less urgent.
This commit fills a test hole found by Codecov: we weren't checking for
the case of a custom time zone whose `id` property returns a non-string
value.
Note that the `id` property is only read in a few places, all on the
ZonedDateTime prototype: `until`, `since`, `equals`, `toString`,
`toLocaleString`, `toJSON`, and `timeZoneId`.
Edits Temporal tests to account for changes in
https://github.com/tc39/proposal-temporal/pull/2574.
This PR stops coercing non-string primitive inputs to strings
in Temporal methods, to avoid cases where numbers
are coerced to syntactically valid but often unexpected
string results.
* Add tests for the new PrepareTemporalFields behavior for all direct callers
See https://github.com/tc39/proposal-temporal/pull/2570
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalDate
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalDateTime
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalZonedDateTime
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalYearMonth
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalMonthDay
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToRelativeTemporalObject
* Add tests for the new PrepareTemporalFields behavior for indirect callers through AddDurationToOrSubtractDurationFromPlainYearMonth
The expectation values for the formatToParts are incorrect.
A. The listFormat is consturcted with
6. Perform ! CreateDataPropertyOrThrow(lfOpts, "type", "unit").
so it should not have " and " in the string. Comparing with
(new Intl.ListFormat("en", {type: "unit"})).formatToParts(["a", "b",
"c"]) and
value in the format d and the expected values in the
DurationFormat/prototype/format directory
B. The localized unit values for "short" (and therefore default)
are incorrect. Comparing with the expected values in the
DurationFormat/prototype/format directory
drop:
property descriptor
name
length
[[Prototype]]
is a function
is not constructible
result instanceof Iterator
limit is given a non-primitive that needs to be converted to a number
through valueOf
through toString (array)
limit coercion to number throws
limit converts to NaN
same as limit not supplied
limit behaves properly
limit < number of values
limit = number of values
limit > number of values
gets the next method from the underlying iterator only once
underlying iterator has throwing next getter
underlying iterator next throws when advancing past dropped items
underlying iterator is advanced after calling drop
underlying iterator is closed after calling drop
underlying iterator is already closed
underlying iterator next returns non-object
underlying iterator next returns object with throwing done/value getters
underlying iterator return is never called when result iterator is closed
every:
property descriptor
name
length
[[Prototype]]
is a function
is callable
is not constructible
result is a Boolean
predicate is non-callable
iterator already exhausted
called on non-object
called on object with "next" method
called on object with non-callable "next" method
predicate returns non-Boolean
predicate returns truthy for all iterated values
returns true
predicate returns truthy for some iterated values but then falsey for at least one iterated value
returns false
iteration stops
iterator is closed
predicate returns falsey immediately
returns false
iteration stops
iterator is closed
predicate throws
every throws
iterator is closed
predicate throws then iterator close also throws
predicate this value is undefined
predicate is passed the yielded value as the first parameter and a counter as second parameter
gets the next method from the iterator only once
iterator has throwing next getter
iterator has throwing return getter
iterator next throws
iterator return throws
iterator next returns non-object
iterator next returns object with throwing done/value getters
Co-authored-by: Michael Ficarra <mficarra@shapesecurity.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
These tests accompany a Temporal PR that works around a bug in
ICU 73.1 (which ships with Node 20). These test changes enable
tests to pass in both the buggy state and after the bug is eventually
fixed.
intl402/Locale/constructor-non-iana-canon.js
- Likely subtags entry for "hyw" -> "hyw-Armn-AM" was added to supplemental/likelySubtags.xml
intl402/Locale/prototype/minimize/removing-likely-subtags-first-adds-likely-subtags.js
- Likely subtags entry for "aae" -> "aae-Latn-IT" was added to supplemental/likelySubtags.xml
- Likely subtags entry for "pap" was changed from "pap_Latn_AW" to "pap_Latn_CW"
As per IETF review, an IXDTF string (ISO 8601 with annotations) is no
longer valid if it contains more than one u-ca annotation and at least one
of the annotations is marked critical.
Removes tests where such a string was assumed to be valid, and adds new
ones with a few variations on invalid strings.
This change affects how PlainYearMonth's add and subtract behave. They
now ignore daysInMonth reimplementations in the calendar, and they call
dateadd() a different number of times.
See https://github.com/tc39/proposal-temporal/issues/1315
Add order-of-operations tests for:
- Temporal.ZonedDateTime.p.getISOFields()
- Temporal.ZonedDateTime.p.round()
- years with ZonedDateTime relativeTo in Temporal.Duration.p.round()
- years with ZonedDateTime relativeTo in Temporal.Duration.p.total()
- property Gets on receiver in Temporal.PlainDateTime.p.with()
- ZonedDateTime difference methods with largestUnit being a time unit
- Duration.compare with no units higher than hours
I wrote a similar test for Temporal.ZonedDateTime.p.toLocaleString, so
while this was fresh I decided to do the same for the other toLocaleString
calendar mismatch tests that were in staging.
In https://github.com/tc39/proposal-temporal/pull/2522 which reached
consensus at the March 2023 TC39 meeting, the functionality of
Temporal.ZonedDateTime.p.toLocaleString was changed substantially, to not
directly pass the ZonedDateTime to any Intl.DateTimeFormat methods. This
adds rewrites of all existing tests for toLocaleString, as well as a few
tests to verify that Intl.DateTimeFormat methods no longer support
Temporal.ZonedDateTime arguments.
As we are rewriting the tests anyway, this also ports all of the
Temporal.ZonedDateTime.p.toLocaleString tests that were in staging, to the
correct format for the main tree.
Before the issue is fixed, rounding a duration such as 'PT2400h' with
months as largest unit fails to balance it properly and gives a result
with days being the largest unit. The test ensures that such rounding
happens properly.
Previously, "nested" calendar property bags were unwrapped up to one
level. That is, this object:
{
calendar: {
// ...Temporal.Calendar methods
}
}
would not be considered to implement the Calendar protocol, but would have
its calendar property used instead, if it were passed to an API that
required a Calendar protocol object.
These nested property bags are no longer supported. Discussion:
https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753
Corresponding normative PR:
https://github.com/tc39/proposal-temporal/pull/2485
Previously, "nested" time zone property bags were unwrapped up to one
level. That is, this object:
{
timeZone: {
// ...Temporal.TimeZone methods
}
}
would not be considered to implement the TimeZone protocol, but would have
its timeZone property used instead, if it were passed to an API that
required a TimeZone protocol object.
These nested property bags are no longer supported. Discussion:
https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753
Corresponding normative PR:
https://github.com/tc39/proposal-temporal/pull/2485
Compare semantics for custom time zones that _don't_ extend
Temporal.TimeZone (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
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>
The Temporal polyfill had a math bug in Calendar.p.dateUntil where
non-ISO calendars would unexpectedly throw when calculating
the number of years between two dates where the year were different,
the month codes were different, but the months were the same because
the earlier date's month was after a leap month.
This test validates the fix to this bug.
The Temporal polyfill had an infinite loop for non-ISO calendars
when Calendar.p.dateUntil was called to calculate the duration
between two identical dates. This test validates that PT0S is returned
in that case.
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.
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.
Adds a test similar to the one in #3697, but in the main tree.
The six code points in this test have an "F" for full case mapping in
CaseFolding.txt, and so they should not be considered in the
Canonicalize operation.
Current versions of SpiderMonkey and V8 fail this test, others pass.
These tests should cover the full functionality of the .groups object (and
the .indices.groups object, in the case of the /d flag) for RegExp.p.exec
and String.p.match:
- Matched DNCG has a result
- Unmatched DNCG is present and undefined
- DNCG matched in previous iteration but not in current iteration is
treated as unmatched
- Iteration order of properties corresponds with source order
See: #3704
Each named capturing group should count as its own parenthesized capturing
group, even if it has the same name as another group. So, some of these
expectations were missing `undefined` array elements for the variant of
the `x` capturing group that didn't match.
In the other expectations, we forgot to take into account that the
backreference is not inside a capturing group, so the group match should
not have doubled letters in it.
Parse-time syntax for RegExp literals is already tested. These two files
test runtime RegExp compilation, with respect to duplicate named capture
groups.
See: #3704
I discovered these tests had omitted some arguments to the PlainDateTime
constructor, leaving the calendar in the wrong position.
The tests were technically not incorrect, since the operation
ToIntegerThrowOnInfinity on the string "gregory" gives 0. But they could
spuriously pass if the implementation didn't do argument conversion
correctly, failed to throw on eraYear being ±Infinity, but subsequently
threw RangeError anyway because the calendars of the arguments didn't
match.
This tests the normative changes in
https://github.com/tc39/proposal-temporal/pull/2245, which achieved
consensus in the July 2022 TC39 meeting, specifically as they apply to the
Temporal.Calendar.prototype.mergeFields method.
Due to the use of the pre-existing spec operation CopyDataProperties, now
symbol keys are merged into the return value, and the order of observable
property operations has changed from a batch of [[GetOwnProperty]]
followed by a batch of [[Get]], to a series of interleaved
[[GetOwnProperty]]/[[Get]] pairs.
This tests some of the normative changes in
https://github.com/tc39/proposal-temporal/pull/2245, which achieved
consensus in the July 2022 TC39 meeting, specifically as they apply to
places where the MergeLargestUnitOperation was called.
Due to the use of the pre-existing spec operation CopyDataProperties, the
order of observable property operations has changed from a batch of
[[GetOwnProperty]] followed by a batch of [[Get]], to a series of
interleaved [[GetOwnProperty]]/[[Get]] pairs. This previously wasn't
tested because TemporalHelpers.propertyBagObserver didn't track
[[GetOwnProperty]] operations, but now it does.
Using assert.deepEqual was faulty here, since deepEqual doesn't take
symbol keys into account. This test wasn't actually testing that the
symbol keys were absent, and in fact passes if they are present.
(Rather than fixing deepEqual, since we hope to deprecate it as per
https://github.com/tc39/test262/issues/3476, add a custom assert function
in the test.)
Normally, a plain object passed into an API that takes a Temporal.TimeZone
has its 'timeZone' property checked (observably) with a Has operation
followed by a Get operation if the property is present. In the normative
change https://github.com/tc39/proposal-temporal/pull/2392 which reached
consensus at the September 2022 TC39 meeting, this was changed so that
this check is skipped for objects which have the Temporal.TimeZone
internal slots.
This adds tests to all entry points that pass a user-supplied object to
ToTemporalTimeZone, with a "poisoned" timeZone object which has the
correct internal slots but a 'timeZone' accessor property whose getter
throws. A correct implementation should not cause this getter to throw.
Normally, a plain object passed into an API that takes a Temporal.Calendar
has its 'calendar' property checked (observably) with a Has operation
followed by a Get operation if the property is present. In the normative
change https://github.com/tc39/proposal-temporal/pull/2392 which reached
consensus at the September 2022 TC39 meeting, this was changed so that
this check is skipped for objects which have the Temporal.Calendar
internal slots.
This adds tests to all entry points that pass a user-supplied object to
ToTemporalCalendar, with a "poisoned" calendar object which has the
correct internal slots but a 'calendar' accessor property whose getter
throws. A correct implementation should not cause this getter to throw.
In these tests, we should make a distinction in the name for clarity. It's
testing a time zone passed as a property in a property bag (either as an
argument, or as a relativeTo option), so name it accordingly as we do with
other tests in the same folder.
This adds tests to WeakMap, WeakSet, WeakRef, and FinalizationRegistry for
Symbols as weakly-held values. Regular symbols and well-known symbols are
both tested. These tests correspond to existing tests for Objects as
weakly-held values, but are put in separate files so that they can be
filtered out with the "symbols-as-weakmap-keys" feature flag.
Registered symbols are not allowed; this is already tested in the "cannot-
be-held-weakly" tests.
See: #2850
There are many existing tests for WeakMap, WeakSet, WeakRef, and
FinalizationRegistry using Objects as weak values. For symbols-as-weakmap-
keys, we'll want to write tests that parallel these for Symbol keys.
Change the descriptions and filenames of these tests to describe their new
scope of only Object weak values.
Update the front matter of these tests while we're at it, to reflect the
changes to the spec text that the symbols-as-weakmap-keys brings in. (In
some cases, remove irrelevant bits of the front matter.)
See: #2850
WeakMap, WeakSet, WeakRef, and FinalizationRegistry all had tests
verifying what would happen if they were called with a value that wasn't
allowed as a weak value: before this proposal, that was a non-Object.
Now, allowed weak values are Objects, well-known Symbols, and unregistered
Symbols. That leaves registered Symbols that are still not allowed as weak
values.
This commit updates those tests to use a registered Symbol instead of an
unregistered Symbol; they should still pass, regardless of whether the
implementation has implemented symbols-as-weakmap-keys yet.
The tests are renamed as appropriate.
Also updates the frontmatter to the most current spec text, including the
CanBeHeldWeakly abstract operation.
See: #2850
This test is duplicated by WeakSet/prototype/add/value-not-object-throw.js
Originally taken from Rick's draft commit for symbols-as-weakmap-keys
tests.
See https://github.com/tc39/proposal-temporal/pull/2316 which eliminated
an observable call to Array.prototype[Symbol.iterator]() in the case where
a calendar's 'fields' property was undefined.
The best way I've thought of to test this is to monkeypatch the
Array.prototype[Symbol.iterator]() method to make it throw. In some cases,
where we are actually expected to iterate the return value from a
Temporal.TimeZone's getPossibleInstantsFor() method, we have to provide a
custom method for that as well, that returns a non-Array iterable so we
don't call the patched Array.prototype[Symbol.iterator]().
This normative change reached consensus at the July 2022 TC39 plenary
meeting.
The programmer always gets the last word over how the string is
interpreted, since otherwise it's not possible to make any guarantees
about the offset option. (This is the "out-of-band" mechanism mentioned in
the IETF draft.) Add a test for this.
Based on the improvements just made to the calendarName option, improve
the tests for the timeZoneName option of ZonedDateTime.prototype.toString
as well.
Since we are going to be adding a new test for calendarName: "critical",
take the existing tests for various values of the calendarName option, and
regularize them. Previously, depending on which type's toString() method
was under test, the tests had various degrees of thoroughness, and some
were only present in staging.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with more than one time zone annotation. These
are not syntactically correct according to the grammar and should be
rejected.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with unrecognized annotations, (i.e., neither
time zone nor calendar), in various combinations with recognized
annotations.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with calendar annotations, with and without the
critical flag, and also a check that the second calendar annotation is
disregarded, as per the IETF draft.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with named and numeric offset time zone
annotations, with and without the critical flag, with various combinations
of Z and offset in front of the annotation.
As of https://github.com/tc39/proposal-temporal/pull/2397 which reached
consensus in the August 2022 TC39 meeting, a date-time + Z with no bracket
annotation is no longer accepted as a relativeTo parameter; either the Z
should be removed or a bracket annotation should be added.
This requires adjusting a few existing tests, but doesn't require any new
ones.
See https://github.com/tc39/proposal-temporal/pull/2267 which eliminated
some unnecessary lookups of the calendar's dateAdd method from the
MoveRelativeDate AO, which is called in the calendar types' since() and
until() methods, Duration.p.round(), and Duration.p.total().
This adds tests for the order of all observable operations for these 10
methods, not just the lookups of dateAdd on the calendar. (These methods
needed to have their order of observable operations tested anyway.)
They heavily use the TemporalHelpers.calendarObserver and
TemporalHelpers.timeZoneObserver added in the previous commits.
https://github.com/tc39/proposal-temporal/pull/2267 included changes to
several code paths, not all of which are reachable through every method
tested here; only Duration.p.round() can trigger the full set.
https://github.com/tc39/proposal-temporal/pull/2267 reached consensus at
the July 2022 TC39 plenary meeting.
Similar to the previous commits with property bags and time zones, there
are also some existing tests that use a Proxy to test the order of
observable operations which involve user code
passed in as part of a Temporal.TimeZone object. I am going to write
several more tests that do this, as well. This seems like a good thing to
put into TemporalHelpers, where it can be implemented consistently so that
we don't get discrepancies in which operations are tracked, or bugs due to
a Symbol-valued property.
Updates existing tests to use this helper.
Similar to the previous commit with property bags, many existing tests use
a Proxy to test the order of observable operations which involve user code
passed in as part of a Temporal.TimeZone object. I am going to write
several more tests that do this, as well. This seems like a good thing to
put into TemporalHelpers, where it can be implemented consistently so that
we don't get discrepancies in which operations are tracked.
Updates existing tests to use this helper.
This adds tests for the normative change in tc39/proposal-temporal#2265,
which adds validation steps to certain abstract operations that call
Temporal.Calendar methods.
These had some duplication with some existing tests named
calendar-returns-infinity.js. Remove these, because the new tests are more
complete in testing what values are accepted.
The existing tests would fail after making the normative change from
tc39/proposal-temporal#2265 because they rely on the getter directly
returning whatever value the calendar method returned. This is no longer
the case, because the value returned by the calendar is validated, so
adjust the assertions in these tests.
Also, no longer any need to return a value from the calendar method that
needs to be converted; we'll add separate tests for that.
Expand these tests to cover all of the PlainDate, PlainDateTime,
PlainMonthDay, PlainYearMonth, and ZonedDateTime property getters that
delegate to the calendar methods.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
Several tests in staging use the Pacific/Apia IANA time zone to test the
behaviour of various algorithms for the case where Samoa skipped the
entire day of Dec. 30, 2011, when they switched from one side of the
International Date Line to the other. Since implementations are not
technically required to support IANA time zones, add a fake Samoa time
zone to TemporalHelpers that has the same transition, and use it in those
tests.
(The time zone isn't exactly the same as Pacific/Apia, since Samoa also
observes DST and this time zone doesn't. It's only the same for this one
transition.)
See: #3649
Some tests in staging used various IANA time zones in order to test DST
behaviour. Since implementations are technically not required to
understand IANA time zones, we have a fake DST time zone in
TemporalHelpers. Use that instead.
For a few cases where it's not practical to use the fake DST time zone
(because it only has one spring-forward and one fall-back transition, for
example), move a few tests into staging/Intl402/Temporal/.
See: #3649
As much as possible, remove non-ISO calendars and IANA time zones from the
Temporal tests in the staging folder.
In most cases, the non-ISO calendar can be replaced with the ISO calendar.
In other cases, create a custom calendar object with the appropriate
return value from toString(), and any other methods needed for that
particular test.
For time zones, in most cases the time zone can be replaced with UTC or a
constant offset time zone. Sometimes a custom time zone object with the
appropriate toString() is sufficient.
Move timezone-america-la.js to staging/Intl402/Temporal/ since its whole
point is to test an IANA time zone. Create a new tzdb-transitions.js in
staging/Intl402/Temporal to test behaviour of Temporal.TimeZone's
getPreviousTransition and getNextTransition for IANA time zones, since
UTC and constant offset time zones always return null for these methods.
There are still some cases where specific DST behaviour is tested. These
will be addressed in following commits.
See: #3649
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
The "half___" modes all round to the nearest increment except when there
is a tie. The previous tests didn't test rounding in the case of any ties
(except for .toString()) so here we use some different numbers in which
there is a tie, in order to make tests where the "half___" modes are more
thoroughly tested.
See https://github.com/tc39/proposal-temporal/pull/2262 which added new
rounding modes from NumberFormat V3.
See https://github.com/tc39/proposal-temporal/pull/2262 which added new
rounding modes from NumberFormat V3.
These tests use the same format as the previous ones. The tests for the
"half" rounding modes aren't very good yet, as they don't show any of the
differences between the tiebreaking schemes; there aren't any ties in the
data to be broken. (Except in .toString().) A subsequent commit will
correct this.
Take all the existing tests for round() calculations using different
rounding modes and standardize them. Add tests for Duration, Instant and
ZonedDateTime, which were still in the old format in staging.
Take all the existing tests for since/until calculations using different
rounding modes and standardize them. Add tests for Instant and
ZonedDateTime, which were still in the old format in staging.
See https://github.com/tc39/proposal-temporal/pull/2262, which reached
consensus in the July 2022 TC39 meeting. This change added several
rounding modes from the NumberFormat V3 proposal, some of which were
listed as invalid in the roundingmode-invalid-string tests. Remove these
items from the list of invalid modes, since they are no longer invalid.
Many existing tests use a Proxy to test the order of observable operations
on a property bag argument that gets passed in to a Temporal API. I am
going to write several more tests that do this, as well. This seems like a
good thing to put into TemporalHelpers, where it can be implemented
consistently so that we don't get discrepancies in which operations are
tracked. (For example, we had some tests which didn't test for an ownKeys
operation that was supposed to be there.)
Updates existing tests to use this helper.
We did this inconsistently in PlainDate and ZonedDateTime, and not in the
other calendar-carrying types. Additionally, we don't have to create the
calendar explicitly in PlainDate.
The doAsserts is not correct for case like "P100000000000000000000000000Y"
If we test "P100000000000000000000000000Y" because the filed in Duration is only required to
"A float64-representable integer is an integer that is exactly representable as a Number value. That is, for a float64-representable integer x, it must hold that ℝ(𝔽(x)) = x." per
https://tc39.es/proposal-temporal/#sec-properties-of-temporal-duration-instances
The duration it hold may produce string such as
"P99999999999999987584860160Y"
even the test only test the first 10 digits ( log(10^10)/log(2) = 33 bits)
Change the test to test
"P100000000000001000000000000Y" instead, so a negative numerical error will not change the start of the string
from "P1000000000" to "P9999999999"
This tests the normative change from
https://github.com/tc39/proposal-temporal/pull/2260
which achieved consensus in the July 2022 TC39 meeting.
The return value from a userland getOffsetNanosecondsFor method is no
longer allowed to be exactly one 24-hour day.
This adds tests that validate a user-callable getOffsetNanosecondsFor to
several APIs that didn't test this yet: ZonedDateTime.since/until, and
Calendar.era/eraYear.
In order for some tests to ensure that they are testing the right
exception, we need to make sure we are in the path where there are no
possible instants for a particular date-time. Override this method in some
tests.
"15Z" will throw RangeError because Z match
UTCDesignator =>
TimeZoneUTCOffset =>
TimeZoneUTCOffset TimeZoneBracketedAnnotationopt =>
TimeZoneopt
and "15" match
1 DecimalDigit =>
Hour =>
TimeHour =>
TimeSpec
so "15Z" match
TimeSpec TimeZoneopt =>
TimeSpecWithOptionalTimeZoneNotAmbiguous =>
TimeSpecWithOptionalTimeZoneNotAmbiguous Calendaropt =>
CalendarTime =>
TemporalTimeString
Therefore
13.37 ParseTemporalTimeString ( isoString )
https://tc39.es/proposal-temporal/#sec-temporal-parsetemporaltimestring
will succeess in 2. If parseResult is a List of errors, throw a RangeError exception.
but the in step 3
3. If parseResult contains a UTCDesignator Parse Node, throw a RangeError exception.
the "Z" is UTCDesignator so it will throw RangeError.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2377 which reached
consensus at the September 2022 TC39 meeting.
It changes the order in which observable operations are performed on the
values passed to the ___fromFields methods of Calendar.
1. add the test for "seconds"
2. since the default value for "style" is "long", baseStyle for GetDurationUnitOptions is "long" and therefore the
last argument in testOption should be "long"
3. the valid values for "days" does not contains "numeric", and "2-digit". remove them.
4. the valid values for "milliseconds", "microseconds" and "nanoseconds" does not contains "2-digit". remove it.
See https://tc39.es/proposal-intl-duration-format/#table-duration-components about the valid value
notice the last colum is for "Digital Default" while the baseStyle is "digital" but the set up does not set it that way, the default value for "style" is "long" as in
```
13. Let style be ? GetOption(options, "style", "string", « "long", "short", "narrow", "digital" », "long").
```
of https://tc39.es/proposal-intl-duration-format/#sec-Intl.DurationFormat
* Sync to PR 121
Change default from "long" to "short"
Due to the TZDB's recent merging of time zones whose pre-1970 data was
different but post-1970 have been the same, this test is going to start
failing on implementations with up-to-date time zone data (because the
Europe/Amsterdam time zone was absorbed into Europe/Brussels in the latest
update.)
It's on our to-do list to remove all dependencies on IANA time zones from
the Temporal tests in staging/,
(see https://github.com/tc39/test262/issues/3649#issuecomment-1232326175)
but this one is more urgent.
This adds an object, TemporalHelpers.ISO, which has methods that return
arrays of various ISO strings. The idea is to deduplicate more string
tests into methods on this object.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2287 which reached
consensus at the July 2022 TC39 meeting.
It adds tests that ensure that PlainTime strings which require a T
designator for disambiguation, are not disambiguated by adding a calendar
annotation.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2284 which reached
consensus at the July 2022 TC39 meeting.
It adds tests that ensure strings like HHMM-UU[TZ] and HHMMSS[TZ] do not
require a disambiguating T separator, even if HHMM-UU and HHMMSS would by
themselves.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2344 which reached
consensus at the July 2022 TC39 meeting.
It adds a test that catches a corner case in Duration.prototype.round().
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.
Ben Allen
André Bargull
Justin Grant
Frank Yung-Fong Tang
Guillaume Emont
Nicolò Ribaudo
Michael Ficarra
Michael Dyck
Shu-yu Guo
Rick Waldron
Jordan Harband
José Julián Espina
Philip Chimento
Veera
Mathias Bynens
Aditi
Aditi
Huáng Jùnliàng
Ms2ger
Richard Gibson
Cam Tenny
Romulo Cintra
Timothy Flynn
snek
jugglinmike
Yusuke Suzuki
Linus Groh
Gokhan Kurt
Rick Waldron
Frank Yung-Fong Tang
Justin Ridgewell
polsevev
Philip Chimento
Kevin Gibbons
Ms2ger
Yusuke Suzuki
Zirak
Romulo Cintra
dnalborczyk