Tweak some tests to provide coverage of new execution paths in the spec,
such as calling GetOptionsObject inside ToTemporal___; add a few new tests
for things that weren't covered before, such as rounding a PlainDateTime
at the edge of the range; and tweak the tests verifying when the
properties of the options bag are read, which I made a mistake in #4119.
See: https://github.com/tc39/proposal-temporal/pull/2925
Previously getISOFields() was used to get the exact value of the
[[Calendar]] and [[TimeZone]] internal slots, as well as to get the
reference ISO year for PlainMonthDay and reference ISO day for
PlainYearMonth.
Use calendarId and timeZoneId for the former and toString() for the
latter.
These are no longer possible without custom objects. Also add an exception
for calendar and timeZone properties in property bag observers so they are
not treated as objects.
Temporarily replace them with getISOFields().calendar/timeZone just to
keep the tests running until we remove Calendar and TimeZone objects
altogether.
See: tc39/proposal-temporal#2826
Following the upstream ECMA-402 change tested in the previous commit, add
test coverage for the corresponding functionality in Temporal. Fix one
test that was erroneous.
These tests were supposed to test an invalid ISO string being used as the
`calendar` property in a property bag. Instead they were testing being
used as an invalid ISO string directly where a PlainDate input was needed.
(That is also already covered elsewhere.)
As per IETF, annotation keys may only consist of lowercase letters,
dashes, and digits, and an optional leading underscore. Uppercase letters
are non-syntactical. Add tests covering this.
Note the monkeypatch of getPossibleInstantsFor in test/built-ins/Temporal/
TimeZone/prototype/getInstantFor/argument-builtin-calendar-no-array-
iteration.js.
Other than that, all the tests are basically identical.
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
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.
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
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
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.
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.
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 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.
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.
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.
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.
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.
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.
ISO strings may separate the time from the date with a case-insensitive T,
or a space. This adds tests to all entry points that take ISO strings, to
ensure that they accept an uppercase T, lowercase T, or space as the time
separator.
These tests are based on the one test for Temporal.PlainDateTime.from that
was already present.
Some of these strings wouldn't have been valid even with a valid year in
them (e.g. strings ending in +01:00[UTC]) so fix up the strings that we
test. While touching these tests, I took the opportunity to regularize
them, and add some missing ones for ISO strings that convert to Calendar
and TimeZone.
Everywhere an ISO string is accepted in Temporal, a seconds value of :60
should always be coerced to :59, because of how leap seconds are handled
in ISO strings.
In property bags, a 'seconds: 60' property is not subject to that rule: it
should be handled according to the overflow option if there is one.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
Each from() method except Calendar and TimeZone should test that when you
pass an instance of that type, the return value is a clone of that
instance, and a distinct object.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
In order to test the referenceISODay of a PlainYearMonth we add an
argument to TemporalHelpers.assertPlainYearMonth.
These tests cover, for every API entry point where a Temporal object is
expected, what happens when a value of a different type is passed in that
can't be converted.
Most entry points can convert a string to the expected Temporal type, and
will do ToString on any non-Object argument, and throw RangeError if the
result isn't a string that's convertible to that Temporal type. ToString
will throw TypeError on a Symbol.
Most entry points also take a property bag, and will throw TypeError if
the property bag doesn't have the required properties.
We also have to test for TimeZone and Calendar what happens if the wrong
type is provided as the value of a 'timeZone' or 'calendar' property in
another property bag, up to one level of nested properties.
Philip Chimento
Justin Grant
Guillaume Emont
Aditi
Philip Chimento