[ptomato]

This batch of commits mainly deals with working around weirdnesses in newer ICU versions, and bugfixes to pass the test262 tests dealing with calendar calculations.

There is one normative change, from the November 2025 TC39 plenary. It deals with rounding durations in edge cases and is unlikely to break any working code.

Closes: #360

[craig-o-curtis]

The normative change in this PR (50d66d2, porting proposal-temporal 5dd0b0d97ee1 / tc39/proposal-temporal#3168) fixes a user-visible wrong answer on main today. Sharing the evidence in case it helps prioritise the review, since the PR description understandably describes it as "unlikely to break any working code".

const from = Temporal.PlainDateTime.from("2024-01-31T00:00:00");
const to   = Temporal.PlainDateTime.from("2024-02-29T12:00:00");

from.until(to, { largestUnit: "month" }).toString();
// "P29DT12H" on both — correct, and the reason r1 is 0 months

from.until(to, { largestUnit: "month", smallestUnit: "month", roundingMode: "trunc" }).toString();
// main: "PT0S"                after 50d66d2: "P1M"

from.until(to, { largestUnit: "month" }).total({ unit: "month", relativeTo: from });
// main: 1.0172413793103448    after 50d66d2: 1.0161290322580645

Temporal.Duration.from("P29DT12H").round({
  smallestUnit: "month", roundingMode: "floor",
  relativeTo: Temporal.PlainDate.from("2024-01-31"),
}).toString();
// main: "PT0S"                after 50d66d2: "P1M"

Both columns are measured here, from two NODE_ENV=production builds — main at c8f344c, and the same tree with 50d66d2 applied on top. The post-fix values agree with Chromium 153.0.8010.12; on #3168 ptomato recorded that SpiderMonkey, temporal_rs and the FullCalendar polyfill agree with V8 too.

Jan 31 + 1 month is Feb 29 only by constraining, so until doesn't count it as a month and r1 is 0. The first window is then Jan 31 → Feb 29, which ends before the Feb 29T12:00 target, so progress exceeds 1 and the result is taken against bounds that don't contain it. In production builds the ${unit} was 0 days long assert is stripped, so it returns a wrong value instead of throwing. Only a relativeTo on the 29th, 30th or 31st can reach it.

Scanning Chromium 153.0.8010.12 against published 0.5.1: total 16 mismatches in 2,016 rows, round 15 in 12,960, until/since with a calendar smallestUnit 15 in 9,940 — all unit: "month", and only in the directed rounding modes (ceil/floor/trunc). The half modes agree either way, because with progress > 1 they still select r2. until without rounding agrees on every row, and Duration.compare reaches no nudge window at all (256 rows, 0 mismatches).

One note for whoever reviews it: #3168's own reproducer (new Temporal.Duration(1, 0, 0, 0, 1) relative to 2020-02-29, unit years) passes on 0.5.1 — there r1 is already 1 from the duration's own years field, so no retry is needed. The month cases above are what expose it, and test262 doesn't cover this yet.

Verification of 50d66d2 applied alone on top of main, Node 24.21.0 / ICU 78.3:

• npm test — 607 passed, 4 suites, 0 failed
• npm run test262 (pinned ac3035f0, production build) — 4855 finished, 4828 passed, 0 failed, 0 passed unexpectedly, 27 expected failures, 6 missing
• npm run lint — clean

It applies cleanly on main by itself and touches only lib/ecmascript.ts, so if it would help to have this one commit split out as a small standalone PR while the rest of the rebase waits for review, I'm happy to open it — just say the word. Otherwise I'll leave it here where it belongs.

Found while testing @northguild/gmt against the specification; it carries a dormant workaround until a release lands.

[Copilot]

Copilot review overview

🟡 Changes recommended

The updated rounding nudging logic can select an incorrect nudgedEpochNs after a retry, and era is no longer treated as a date option in Intl-style defaulting, both of which can produce incorrect observable behavior.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2

Open (2)

• era option ignored in yearMonthAmend · New
• era option excluded from hasDateOptions · New

What changed in this PR

This PR continues the April 2026 rebase work by adding/adjusting ICU workarounds for non-ISO calendars (notably Chinese/Dangi/Coptic/Ethiopic) and updating internal rounding logic to match the November 2025 TC39 normative change, with the goal of improving test262 pass rates across newer ICU versions.

Changes:

• Updated calendar parsing/validation to handle newer ICU month/era quirks (e.g., Chinese/Dangi “Mo…” month parts, Coptic era omissions).
• Refactored and extended relative-duration rounding (“nudge”) logic for calendar-unit rounding edge cases.
• Updated test expected-failure lists to reflect known ICU behavior regressions/bugs.

File	Description
test/​expected-failures.txt	Adds new expected failures for Chinese calendar monthCode tests due to ICU4C leap-month issues.
test/​expected-failures-cldr48.txt	Removes CLDR48-specific expected failures and adjusts the remaining set for current behavior.
lib/​intl.ts	Changes option-amend/defaulting logic for Temporal toLocaleString, including new handling around era.
lib/​ecmascript.ts	Refactors calendar-unit nudging window computation and rounding behavior for relative durations.
lib/​calendar.ts	Implements multiple ICU workarounds and strengthens calendar field resolution/validation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[justingrant]

Looks great, thanks for porting these commits, we're getting close to present day!

Copilot had some feedback you may want to look at, but I didn't see anything obvious to worry about.