drop:
property descriptor
name
length
[[Prototype]]
is a function
is not constructible
result instanceof Iterator
limit is given a non-primitive that needs to be converted to a number
through valueOf
through toString (array)
limit coercion to number throws
limit converts to NaN
same as limit not supplied
limit behaves properly
limit < number of values
limit = number of values
limit > number of values
gets the next method from the underlying iterator only once
underlying iterator has throwing next getter
underlying iterator next throws when advancing past dropped items
underlying iterator is advanced after calling drop
underlying iterator is closed after calling drop
underlying iterator is already closed
underlying iterator next returns non-object
underlying iterator next returns object with throwing done/value getters
underlying iterator return is never called when result iterator is closed
every:
property descriptor
name
length
[[Prototype]]
is a function
is callable
is not constructible
result is a Boolean
predicate is non-callable
iterator already exhausted
called on non-object
called on object with "next" method
called on object with non-callable "next" method
predicate returns non-Boolean
predicate returns truthy for all iterated values
returns true
predicate returns truthy for some iterated values but then falsey for at least one iterated value
returns false
iteration stops
iterator is closed
predicate returns falsey immediately
returns false
iteration stops
iterator is closed
predicate throws
every throws
iterator is closed
predicate throws then iterator close also throws
predicate this value is undefined
predicate is passed the yielded value as the first parameter and a counter as second parameter
gets the next method from the iterator only once
iterator has throwing next getter
iterator has throwing return getter
iterator next throws
iterator return throws
iterator next returns non-object
iterator next returns object with throwing done/value getters
Co-authored-by: Michael Ficarra <mficarra@shapesecurity.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
These tests accompany a Temporal PR that works around a bug in
ICU 73.1 (which ships with Node 20). These test changes enable
tests to pass in both the buggy state and after the bug is eventually
fixed.
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
Linus Groh
Shu-yu Guo
Rick Waldron
Jordan Harband
Justin Grant
José Julián Espina
Philip Chimento
André Bargull
Veera
Mathias Bynens
Guillaume Emont
Aditi
Anthony Frehner
Aditi
Frank Tang