See tc39/proposal-temporal#2825.
Various edits to existing tests so that they make more sense with the
removal of relativeTo.
New tests specifically testing that calendar units cannot be added or
subtracted directly.
See tc39/proposal-temporal#2825. This is a mass removal of tests that use
this functionality, in a separate commit for ease of review. Further
adjustments will be made in the following commit.
This covers an edge case that we hit, where 24 hours would not balance up
to one day in a 25-hour day if only largestUnit was specified, but would
erroneously balance up if rounding was also performed by specifying
smallestUnit.
In ZonedDateTime.p.since/until, it's possible for AddDateTime to hit the
limit if the rounding increment is very high, even if the resulting
rounded duration isn't outside of the limit. Add a test covering this
case.
This should produce all the same results (except for a change to weeks
balancing in round(), which is now more consistent with since()/until())
but leads to different observable user code calls.
See https://github.com/tc39/proposal-temporal/issues/2742
* RAB: Integrate staging tests for .byteLength method
of TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
* RAB: Integrate staging tests for .at method
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
It was previously not tested what options value a custom calendar's
dateFromFields() method would be called with, when called from the
toPlainDate() method of PlainYearMonth/PlainMonthDay.
See tc39/proposal-temporal#2803
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.)
Due to overlooked copy-paste errors we were creating the wrong type of
instance in these tests, and therefore testing the wrong method.
(Add blank line for consistency with the other instances of these tests.)
After rounding relative to a ZonedDateTime, we have to potentially adjust
for DST. With a time zone providing nonsensical values, the duration may
go out of range.
See: tc39/proposal-temporal#2801
This test isn't testing what the assertion message previously said it was
testing. The integer is allowed to be unsafe, but in this case its
float64-representation is out of range.
See: https://github.com/tc39/proposal-temporal/issues/2785
With test cases kindly provided by Anba, this adds test coverage for the
abrupt completion in the last step of DifferenceTemporalPlainDateTime,
where the resulting Duration components have mixed signs.
See: https://github.com/tc39/proposal-temporal/issues/2783
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
