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
- normal case with synchronous and asynchronous mapfn
- a non-callable value is passed as mapfn
- behaviour of various values of thisArg in strict and sloppy mode
- mapfn result is awaited once per iteration
- iterator is closed when mapfn throws
A property in the property bag we want to observe may be a function, in
which case we don't want to treat it as a primitive and create a
toPrimitiveObserver for it.
(Also handle the null case, in which we should fall through to return a
toPrimitiveObserver.)
This was a needs-consensus PR that didn't reach consensus. The
corresponding tests were already removed in f7e6656c.
(Note, the link in the removed comment is wrong; it should point to
https://github.com/tc39/ecma402/issues/374)
Previously, split() would split on whitespace, then the if-condition would
remove `#` - interpreting every word in every comment in the file as a
potential valid feature flag. We want splitlines() here.
Partial-line comments were inadvertently "supported" before, because of
this bug. Instead, support them explicitly by chopping off a `#`
character, anything after it, and any whitespace immediately preceding it.
If a specific Python interpreter is used (e.g. by invoking the script with
"/path/to/python run.py") then we should use the same Python interpreter
to execute scripts in subprocesses, not the one from the environment.
The path to the running Python interpreter is given by sys.executable.
Philip Chimento
Guillaume Emont
André Bargull
Aditi
Frank Tang
Justin Grant
Aditi
Huáng Jùnliàng
Jordan Harband
Shu-yu Guo
José Julián Espina
Ms2ger
Richard Gibson
Cam
Cam Tenny