You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two intl402/Temporal conformance gaps in the `toLocaleString`/calendar tail
(#5580), clearing 29 test262 cases (intl402/Temporal 105 → 76 runtime-fails,
parity 94.8% → 96.3%) with no regressions:
1. **Reject the bare `islamic` calendar in Temporal.** `temporal_rs` accepts
`islamic` (no `-civil`/`-tbla`/`-umalqura` variant) by falling back to the
tabular-Friday Hijri epoch, but per Intl-Era-monthcode a bare `islamic` is
only valid in the `Intl.DateTimeFormat` constructor, not as a Temporal
calendar identifier. `calendar_slot` / `calendar_identifier` now throw a
`RangeError` for it, so `Temporal.PlainDate.from({ calendar: "islamic" })`
and the other `from`/constructor paths reject as the spec requires.
(`{PlainDate,PlainDateTime,PlainMonthDay,PlainYearMonth,ZonedDateTime}/from/islamic.js`)
2. **Render `Temporal.*.prototype.toLocaleString` instead of `[object Object]`.**
The runtime `toLocaleString` tag-dispatcher (`js_object_default_to_locale_string`)
now routes a Temporal value to its own per-type formatter and enforces the
spec's calendar-mismatch `RangeError`. Output is derived from the
calendar-aware accessors: since the ISO-8601 calendar *is* the proleptic
Gregorian calendar those accessors are identical for an `iso8601` and a
`gregory` instance of the same date, and `assert_locale_string_calendar`
rejects every other calendar — so the rendering is calendar-agnostic, as the
`calendar-mismatch` cases require. Fixes calendar-mismatch, era,
default-includes/excludes-field, ignore-timezone, and resolved-time-zone
cases across PlainDate/PlainDateTime/PlainTime/PlainYearMonth/PlainMonthDay/
ZonedDateTime.
Known follow-up: the `locales`/`options` arguments are dropped by the
`Expr::DateToLocaleString` HIR lowering before reaching the runtime, so the
option-conflict `TypeError`s (`dateStyle`+`timeStyle`, component+style, a
`timeZone` on a ZonedDateTime) and explicit non-default `calendar`/style
formatting are not yet honored — threading those args through that lowering is
the next step.
Co-authored-by: Ralph <ralph@skelpo.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments