Fix accidental lowercasing

Miscellaneous improvements

• Hide exponentiation arrows even outside emu-alg.
• Never add them for .
• Wrap a not-fully-text exponent in hidden parentheses unless already present OR it contains no spaces.
• Rearrange the step replacement example to start at a non-initial index.

Update baselines

Fixes #516

Make some trivial changes to the spec for demonstrating handling

Update baselines

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.

"one of" is an alias for "either" (#514)

Version 16.0.1

Update DateTimeFormat proleptic Gregorian testing to include era (#3722)

Ref https://github.com/tc39/ecma402/issues/723

Ref https://github.com/tc39/ecma402/issues/723

CI: Disable GraalJS.

Ref. #3703.

Fix esids

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

Update .github/workflows/esmeta-test262.yml

Co-authored-by: Jordan Harband ljharb@gmail.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

The 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:

Let year be 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:

$ eshost -e 'new Date(Date.parse("+000000-01-01")).toLocaleDateString(undefined, {era:"short", timeZone:"UTC"})'
#### ChakraCore
1 1, 1 BC

#### engine262

Error: Date.prototype.toLocaleDateString is not implemented

#### GraalJS
1/1/1 BC

#### JavaScriptCore
1 1, 1 BC

#### Moddable XS
Fri Dec 31 -0001

#### QuickJS
12/31/-0001

#### SpiderMonkey
1/1/1 B

#### V8
1/1/1 BC

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.)

Normative: Correct Gregorian calendar BC(E) era to signed years less than 1 AD

Fixes #723

Fixes #723

This change achieved consensus at the TC39 plenary of 2023-01-31.