I'm thinking up-arrow notation for elements that can't be translated directly. PR incoming.
Elements such as
<sup> in data copied from spec content are replaced with their textContent when pasting as plain text, which can result in semantically inappropriate transformations such as (plucking real-word cases from Number.prototype.toFixed) "If x ≥ 1021" → "If x ≥ 1021" and "n / 10f - x" → "n / 10f - x".
This is a common need when writing test262 tests (cf. https://github.com/tc39/test262/blob/main/CONTRIBUTING.md#info ), so we should try to improve the experience similarly to what was done for step labels in #290.
CI: Disable GraalJS.
Temporal: Move more collections of valid/invalid strings into TemporalHelpers
The idea is to deduplicate more string tests into methods on this object, that return collections of valid and invalid strings. This adds collections of valid and invalid PlainYearMonth and PlainMonthDay strings.
Temporal: Remove duplicate number-as-PlainMonthDay test case
Conversion of a Number to an ISO string is already covered in the file argument-number.js.
Temporal: Expand PlainYearMonth and PlainMonthDay strings tests
Use the new collections of strings in TemporalHelpers.ISO to add more tests for ISO strings in API entry points that convert an ISO string to Temporal.PlainYearMonth or Temporal.PlainMonthDay.
test/built-ins/TypedArray/prototype/map/callbackfn-resize.js test result is incorrect (#3721)
%TypedArray%.prototype.map's iteration count does not change even though the source view is resized during the iteration. And since result is just returning index, then result array should be [0, 1, 2].
CI: Integrate ESMeta
Co-authored-by: Jordan Harband email@example.com
Append newline and use working_directory
Temporal: Add offset field to order-of-operations tests
There are additional observable operations that occur when providing an
offset property in a relativeTo or ZonedDateTime property bag. We can
test these in our existing order-of-operations tests.
Temporal: Expand order-of-operations tests to cover different types of relativeTo
relativeTo parameter in an options bag may be undefined, a PlainDate
instance, or a ZonedDateTime instance. Each of these three possibilities
causes a different set of observable operations, which we can test in our
existing order-of-operations tests.
Temporal helpers: Track daysInMonth() in calendarObserver()
The Temporal.Calendar.prototype.daysInMonth() method is observably called in a few places in the spec. It should be tracked on the object returned from TemporalHelpers.calendarObserver().
Temporal: Expand order-of-operations tests to cover options bags
Some of the existing order-of-operations tests didn't pass an options bag: primarily from(), with(), add() and subtract(). (since() and until() were covered in a previous commit.)
Add a TemporalHelpers.propertyBagObserver() options bag to the invocations of these methods in the order-of-operations tests.
Temporal: Expand order-of-operations tests to cover calendar methods
Some of the existing order-of-operations tests didn't observe the calendar operations. Add a TemporalHelpers.calendarObserver() calendar to the invocations of these methods in the order-of-operations tests.
Temporal: Observe ToString of calendar property in Temporal.PlainTime.from
Similar to the previous commit, but with a toPrimitiveObserver instead of a calendarObserver, which would cause PlainTime.from() to throw.
Temporal: Add some more order-of-operations tests
This adds order-of-operations tests that cover all of the Temporal entry points that accept options bags, that were not already covered. We'll be using these tests in the future to verify https://github.com/tc39/proposal-temporal/issues/2254 However, the tests in this commit reflect the current state of the proposal, not the potential normative change.
Temporal: Clean up existing uses of foo.splice(0, foo.length)
The second parameter isn't needed if the intention is to empty the array. Additionally clearing it at the end of the test isn't needed.
Update expected results for CLDR 42
Temporal: Update tests to use internal slot in TimeZone and Calendar.id
In https://github.com/tc39/proposal-temporal/pull/2411, to be proposed for consensus in TC39 in December, the .id getter of TimeZone and Calendar should no longer call toString().
Temporal: Add test for Calendar.id with custom calendar
We already have a similar test covering TimeZone.id that ensures toString is not called. We did not have this coverage yet for Calendar.id, so adapt the TimeZone test for Calendar.
https://github.com/tc39/ecma402/pull/729 achieved consensus at the TC39 plenary of 2023-01-31.
In the [[Era]] row of https://tc39.es/ecma402/#table-datetimeformat-tolocaltime-record:
YearFromTime(tz)specified in es2023's Year Number. If year is less than 0, return 'BC', else, return 'AD'.
This should be "less than 1" because ISO year 0 is the year 1 BC (or 1 BCE if you prefer the "common era" nomenclature). There is no year 0 BC or 0 AD.
I ran a quick check with eshost, and none of the engines that I have installed implement the spec as written:
As you can see, output varies quite a lot, but for all the engines that do include an era in the output, it is always BC for ISO year 0. So this change would reflect web reality.
(Spotted by @gibson042.)
This change achieved consensus at the TC39 plenary of 2023-01-31.