* Temporal: Tests for duration rounding and totaling
This provides coverage for the bug in https://github.com/tc39/proposal-temporal/issues/3168
* Update test/built-ins/Temporal/Duration/prototype/total/rounding-window.js
---------
Co-authored-by: Philip Chimento <philip.chimento@gmail.com>
The spec describes the internal representation of Duration as float64-
representable integers. There are a few tricky ways that it is
observable if an implementation does not do this correctly. Here are
some tests for them.
These tests confirm that Temporal-object-like property bags have the
correct default values for their optional properties.
This provides coverage for a V8 bug:
https://issues.chromium.org/issues/446728405
These tests cover the normative change approved in the July 2025 TC39
plenary. See https://github.com/tc39/proposal-temporal/pull/3130.
All properties of user-passed options objects should be read and cast
before any "algorithmic validation" is done.
This is a lot of tests, that cover every entry point where an options
object is passed in, where subsequently an exception can be thrown or user
code can be called.
However, the normative change only affects 10 of these tests:
- Instant.p.since,until,toString
- PlainDate.p.since,until
- PlainTime.p.since,until
- PlainYearMonth.p.since,until
- ZonedDateTime.p.toString
The other 35 tests simply close a gap in coverage.
See: tc39/proposal-temporal#3121
A type assertion in the spec was incorrect, but the assertion wasn't hit
in the Firefox implementation in any test262 test. These three tests add
coverage for all the paths that would have hit that assertion.
Changes made to:
- PlainDate
- PlainYearMonth
- ZonedDateTime
- PlainDateTime
- PlainMonthDay
Merged calendar-number.js and calendar-wrong-type.js, due to no special behaviour of number to be tested.
Extracted string tests to calendar-iso-string.js and renamed the file to calendar-invalid-iso-string.js, due to the contents of the file initially testing invalid ISO strings.
Closes#3873
These tests did not fully cover Temporal.Duration.prototype.round and
Temporal.Duration.prototype.total because they called those methods on a
blank duration (all components zero), for which there is an early return
in round() and total().
This meant that we missed an assertion that would be hit after the early
return.
This makes sure to test both blank and non-blank Durations with these
relativeTo strings, and expect some strings to fail at different steps
with the two cases.
See: tc39/proposal-temporal#3015
* Temporal: Move most tests out of total.js under staging into separate files under test/built-ins
Co-authored-by: Philip Chimento <philip.chimento@gmail.com>
Remove the existing "instant-string-limits.js" that only applied to APIs
where ToTemporalInstant was called. Add "argument-string-limits.js" tests
everywhere ISO strings are converted.
Related to tc39/proposal-temporal#2985
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
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.
Many tests tested some functionality while asserting that there were no
calls of calendar or time zone methods. We can continue testing the
functionality, but there are no more methods to call, so we can delete
those parts of the tests.
It's no longer possible to fake built-in time zones using custom objects.
So testing DST shifts will have to use real built-in time zones. Replace
TemporalHelpers.springForwardFallBackTimeZone with America/Vancouver (it
was modelled on the DST transitions in 2000) and
TemporalHelpers.crossDateLineTimeZone with Pacific/Apia (it was modelled
on the 2011 switch to the other side of the international date line.)
These tests have to move to the intl402/ folder since non-Intl-aware
implementations are allowed (but not required) to support any built-in
time zones other than UTC.
In many cases we created a TimeZone or Calendar instance from a built-in
time zone or calendar. These tests can be trivially adapted to just use
the string ID.
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.
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
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
