Using `\p{ID_Start}` and `\p{ID_Continue}` to match JS identifiers was not
supported everywhere. Let's assume that we only want to format ASCII
identifiers as bare property names. (This doesn't change any tests, just
the formatting of property names in lists of user-observable actions. No
tests currently checked for non-ASCII properties.)
intl402/Locale/constructor-non-iana-canon.js
- Likely subtags entry for "hyw" -> "hyw-Armn-AM" was added to supplemental/likelySubtags.xml
intl402/Locale/prototype/minimize/removing-likely-subtags-first-adds-likely-subtags.js
- Likely subtags entry for "aae" -> "aae-Latn-IT" was added to supplemental/likelySubtags.xml
- Likely subtags entry for "pap" was changed from "pap_Latn_AW" to "pap_Latn_CW"
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
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.
In https://github.com/tc39/proposal-temporal/pull/2522 which reached
consensus at the March 2023 TC39 meeting, the functionality of
Temporal.ZonedDateTime.p.toLocaleString was changed substantially, to not
directly pass the ZonedDateTime to any Intl.DateTimeFormat methods. This
adds rewrites of all existing tests for toLocaleString, as well as a few
tests to verify that Intl.DateTimeFormat methods no longer support
Temporal.ZonedDateTime arguments.
As we are rewriting the tests anyway, this also ports all of the
Temporal.ZonedDateTime.p.toLocaleString tests that were in staging, to the
correct format for the main tree.
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
This contains a few more tests for Array.fromAsync, in addition to what
has already been merged and what is under review at #3791.
This covers the following items from the testing plan at #3725:
- Success cases
- Creates promise
- Create new array/arraylike in promise (with length = length property)
- Input
- Invalid input values
- nonconforming object (arraylike without length, missing keys)
- Covered by polyfill tests
- Result promise rejects if length access fails (non-iterable input)
- Unaffected by globalThis.Symbol mutation (non-iterable)
- this-value
- this-value is a constructor
- this-value is not a constructor
- If this is a constructor, and items doesn't have a Symbol.iterator,
returns a new instance of this
- Iterator closed when property creation on this fails
- Returned promise rejects when ^
- Other tests
- Error is thrown for all CreateDataProperty fails
- Non-writable properties are overwritten by CreateDataProperty
- Input with missing values
Co-authored-by: Ms2ger <Ms2ger@igalia.com>
The Temporal polyfill had a math bug in Calendar.p.dateUntil where
non-ISO calendars would unexpectedly throw when calculating
the number of years between two dates where the year were different,
the month codes were different, but the months were the same because
the earlier date's month was after a leap month.
This test validates the fix to this bug.
The Temporal polyfill had an infinite loop for non-ISO calendars
when Calendar.p.dateUntil was called to calculate the duration
between two identical dates. This test validates that PT0S is returned
in that case.
This adds copies of the tests added in the previous commit, to the
respective BigInt folders, editing them to use the testBigIntTypedArray
helper instead of the testTypedArray helper.
See: #3723
Philip Chimento
André Bargull
Jordan Harband
Veera
Mathias Bynens
Guillaume Emont
Aditi
Anthony Frehner
Aditi
Frank Tang
Justin Grant
Huáng Jùnliàng