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.
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.
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.
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.
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.
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().
