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.
Adds tests that verify that Instant strings cannot include offset time
zone annotations with sub-minute units.
Also removes a few staging test cases that, due to a polyfill bug, were
incorrectly passing.
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.
I noticed a small test hole in codecov: we weren't testing
Temporal.Instant parsing with trailing zeroes in the offset.
I also didn't see fractional offset testing, so added that too.
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.
This change affects how PlainYearMonth's add and subtract behave. They
now ignore daysInMonth reimplementations in the calendar, and they call
dateadd() a different number of times.
See https://github.com/tc39/proposal-temporal/issues/1315
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
Before the issue is fixed, rounding a duration such as 'PT2400h' with
months as largest unit fails to balance it properly and gives a result
with days being the largest unit. The test ensures that such rounding
happens properly.
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
