For each Temporal type, add a test (which should not be sensitive to the
exact locale format) that ensures dateStyle affects the output, for a
Gregorian and non-Gregorian calendar.
See https://github.com/tc39/proposal-temporal/issues/2058
I wrote a similar test for Temporal.ZonedDateTime.p.toLocaleString, so
while this was fresh I decided to do the same for the other toLocaleString
calendar mismatch tests that were in staging.
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
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
I discovered these tests had omitted some arguments to the PlainDateTime
constructor, leaving the calendar in the wrong position.
The tests were technically not incorrect, since the operation
ToIntegerThrowOnInfinity on the string "gregory" gives 0. But they could
spuriously pass if the implementation didn't do argument conversion
correctly, failed to throw on eraYear being ±Infinity, but subsequently
threw RangeError anyway because the calendars of the arguments didn't
match.
For cases in the previous commit that actually removed some functionality
from tests in built-ins/, add corresponding tests in intl402/ to preserve
test coverage of that functionality for hosts that do support Intl.
Move part of the test of toLocaleString which depends on
15 Amendments to the ECMAScript® 2021 Internationalization API Specification
to intl402. Keep behavior specified in earlier chapters in built-ins
Unfortunately, in #3304 I made a last-minute mistake when I added the
uncallable value to the assertion message, and neglected to test it;
Symbols can't be converted to strings like that, so these tests would
fail. This fixes the assertion messages.
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1829
In a previous version of the specification, there was a fallback to the
intrinsic getOffsetNanosecondsFor when it was undefined.
Philip Chimento
Aditi
Richard Gibson
Justin Grant
Frank Yung-Fong Tang
Jesse Alama
Ms2ger
Philip Chimento
André Bargull