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.)
normalized-time-duration-to-days-range-errors.js tests for several error
cases in the AO NormalizedTimeDurationToDays. Adding assertion messages
helps to know which one you are debugging.
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.
These test cases ensure that DST disambiguation does not take place on
intermediate values that are not the start or the end of the calculation.
Note that NormalizedTimeDurationToDays is no longer called inside
Temporal.Duration.prototype.add/subtract, so a few tests can be deleted.
Other tests need to be adjusted because NormalizedTimeDurationToDays is
no longer called inside Temporal.ZonedDateTime.prototype.since/until via
DifferenceZonedDateTime, although it is still called as part of rounding.
In addition, new tests for the now-fixed edge case are added, and for the
day corrections that can happen to intermediates.
See https://github.com/tc39/proposal-temporal/pull/2760
This adds tests specifically for every kind of case that changes due to
the tweak to the date difference algorithm: differences from a longer
month to a shorter month, when the months are adjacent, in the same year
but not adjacent, and in different years.
Also adds tests for a case that does *not* change, but would trip on an
incorrectly implemented algorithm: when the intermediate months value
falls at the end of February.
There was incidental coverage of the change to the date difference
algorithm in other tests. Those are adjusted, as well.
Normative change: https://github.com/tc39/proposal-temporal/pull/2759
Consensus in February 2024
Adapts the tests that checked arbitrarily long loops, to now check that an
exception is thrown if the loop would happen.
Adds tests that exercise the newly added checks on return values of
getPossibleInstantsFor and getOffsetNanosecondsFor that limit UTC offset
shifts to 24 hours or less.
Also updates some step numbers in related tests.
The existing tests didn't cover some edge cases where implementations
have to compute the exact result of `numerator / denominator`, where at
least one of `numerator` and `denominator` can't be exactly represented
by an IEEE-754 double precision floating point value.
"precision-exact-mathematical-values-5.js" gets added in #3961, so the
new tests from this commit start at "precision-exact-mathematical-values-6.js".
NormalizedTimeDurationToDays can no longer loop indefinitely, because at
a certain point we will hit the upper bound of MAX_SAFE_INTEGER, so rename
the test to reflect that it can loop an arbitrary but limited number of
times.
Add a test for the RangeError condition in NormalizedTimeDurationToDays
when the time zone calculates a day length that is not a safe integer
number of nanoseconds.
While editing these tests, rename them to match the current name of the AO
and make sure the step numbers are up to date. (Normally I wouldn't care
so much about that, but these tests can be pretty confusing so it's good
to be able to refer to the spec text.)
Adapts or removes tests that relied on creating durations that are now out
of range. Adds new tests for maximum in-range and minimum out-of-range
durations.
A few results change because the algorithm previously used for rounding
didn't always add duration units to dates in RFC 5545 order, and we also
introduce a special case for rounding with largestUnit years or months and
smallestUnit weeks.
In order to fixtc39/proposal-temporal#2563, we added invocations of
BalanceDurationRelative after some invocations of RoundDuration. These
cause observable calendar calls, which must be accounted for in some
existing tests.
See https://github.com/tc39/proposal-temporal/issues/2563
The old behaviour was encoded in one test in staging, but the behaviour of
largestUnit in duration rounding has changed since that test was written.
Therefore I'm assuming that toString() should've been updated when that
happened.
In the AO DisambiguatePossibleInstants, a PlainDateTime instance is passed
to user code. This instance should have the built-in ISO 8601 calendar.
Here are some tests that ensure it does.
See tc39/proposal-temporal#2671.
This removes several loopholes where it was possible to return particular
values from user calls that would cause infinite loops, or calculate
zero-length days.
This allows removing several tests, as calendar.dateAdd() is no longer
called in several places, and it's no longer possible to create a
situation where BigInt arithmetic is observable in NanosecondsToDays.
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.
Adds new tests to order-of-operations.js in Duration.round and
Duration.total, to exercise the code path where previous to this normative
change, relativeTo would have been converted to PlainDate 3x and 2x,
respectively.
This shortcut path now exists in all round(), since(), and until()
operations.
In Instant, PlainDate, PlainDateTime, and PlainTime, the change isn't
observable, so no tests could be added. This adds test coverage for
- Duration.p.round()
- PlainYearMonth.p.since()
- PlainYearMonth.p.until()
- ZonedDateTime.p.round()
- ZonedDateTime.p.since()
- ZonedDateTime.p.until()
As well as a few cases where we are testing that certain calendar methods
get called during a round operation, but previously were doing so with
options that now become a no-op and no longer call those calendar methods.
In those cases, round to 2 ns, rather than 1 ns.
This commit verifies that ISO strings with sub-minute offsets cannot
be parsed into time zone identifiers. This was a change introduced in
the recently-merged tc39/proposal-temporal#2607, but tests for this case
were missing from #3862 (the tests for that PR).
I noticed in codecov results on an unrelated PR that this case wasn't
being tested, so fixing that mistake now.
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
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.
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
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
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.
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.
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.
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.
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.
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.
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.
Adam Shaw
Philip Chimento
Aditi
André Bargull
Justin Grant
Guillaume Emont
Richard Gibson
Cam Tenny