@northguild/gmt 1.14.2 → 1.16.0

package/dist/internal/calendarDateString.js

@@ -1,103 +1,61 @@
 import { Temporal } from "@js-temporal/polyfill";
-import { calendarDate, plainDate } from "../regex/index.js";
-import { calendarSystemIdFromTemporal, isCalendarSystem, temporalCalendarIds, } from "./calendarSystemIds.js";
-import { dateFromEthiopicFamilyFields, isEthiopicFamilyCalendar, } from "./ethiopicFamilyCalendar.js";
+import { plainDate } from "../regex/date.js";
+import { plainDateTime } from "../regex/date-time.js";
+import { canonicalCalendarSystem, computationCalendarId, } from "./calendarSystemIds.js";
+import { isoStringBody } from "./isoStringBody.js";
 /**
- * Parse a plain ISO PlainDate string or a GMT calendar-annotated PlainDate string
- * (`"5785-01-01[u-ca=hebrew]"`, calendar-native fields, not Temporal's own ISO-digit
- * `[u-ca=...]` annotation convention) into a Temporal.PlainDate. Throws on invalid input —
- * callers wrap this in try-catch per GMT's sentinel-return contract.
+ * Second `60` in the time of day, before any `[`: `T`, `t` or space separator, extended or basic
+ * digits. Temporal's ParseISODateTime clamps it to `:59`; GMT's Plain date-time inputs reject it
+ * (`isValidDateTime`, a duration `relativeTo`). Unlike `regex/leap-second.ts`, no designator is
+ * required, because a Plain string has none.
+ */
+export const temporalStringLeapSecond = /^[^[]*?[Tt ]\d{2}:?\d{2}:?60(?:[.,]\d+)?(?:[-+Zz[]|$)/;
+/**
+ * Parse a GMT calendar date string into a Temporal.PlainDate, exactly as `Temporal.PlainDate.from`
+ * reads it, restricted to GMT's written shape and GMT's calendars. Throws on invalid input — callers
+ * wrap this in try-catch per GMT's sentinel contract.
  *
- * The regex only proves shape; `Temporal.PlainDate.from` performs the real construction
- * and validation (rejecting overflowed fields and unknown calendar identifiers), per the
- * scoped manual-string-parsing exception for fixed, non-caller-supplied grammars. The
- * Ethiopic family ("ethiopic" / "ethiopic-amete-alem" / "coptic") is the one exception —
- * see ethiopicFamilyCalendar.ts for why they're constructed via GMT-owned arithmetic
- * instead of Temporal's own calendar ids for those three.
+ * - The part before the first `[` must be GMT's strict extended date (`plainDate`) or date-time
+ *   (`plainDateTime`), as `isValidDate` and `isValidDateTime` require. Basic
+ *   format (`20241003`), a space or lower-case `t` separator and a UTC offset are rejected, although
+ *   `Temporal.PlainDate.from` reads them. Only then does Temporal read the annotations.
+ * - An ISO date, optionally followed by RFC 9557 annotations (`"2024-10-03[u-ca=hebrew]"`, which is
+ *   what `Temporal.PlainDate#toString()` writes). The digits are always the ISO date; the annotation
+ *   names the calendar (RFC 9557 §3.3).
+ * - A date-time is read as its date, as `Temporal.PlainDate.from` reads it
+ *   (`"2024-10-03T14:30[u-ca=hebrew]"` is 2024-10-03 in Hebrew): the time is dropped. A leap
+ *   second (second `60`) is rejected, as every GMT Plain date-time input rejects it.
+ * - The annotations follow Temporal's ISO grammar (`ParseISODateTime`): a time zone annotation
+ *   and elective unknown annotations (`[foo=bar]`) are read and ignored, the first `u-ca`
+ *   annotation names the calendar, and an unknown critical annotation (`[!foo=bar]`) or a second
+ *   `u-ca` annotation when either one is critical is rejected. `Temporal.PlainDate.from` applies
+ *   those rules and canonicalizes the id (`HEBREW` → `hebrew`, `islamicc` → `islamic-civil`,
+ *   `ethiopic-amete-alem` → `ethioaa`).
+ * - The calendar must be a `CalendarSystem`. Temporal also knows `chinese`, `dangi`, `islamic` and
+ *   `islamic-rgsa`, which GMT does not support.
+ * - The result computes in `computationCalendarId(calendar)`: `"ethiopic"` and `"coptic"` are read
+ *   in `"ethioaa"`, so callers that write a string back take the calendar from
+ *   `calendarSystemOfDateValue(value)`, not from `date.calendarId`.
  *
- * The non-annotated fallback branch requires the strict PlainDate-only shape (via the
- * `plainDate` regex) before delegating to `Temporal.PlainDate.from` — bare `.from()` silently
- * truncates a full datetime/zoned string to its date portion (`Temporal.PlainDate.from("2024-
- * 03-10T14:30:00")` succeeds), which would make this function (and therefore
- * `isValidCalendarDate`/`convertDateToCalendar`) wrongly accept datetime input. Found and
- * fixed as part of E5 (issue #78) — it predates this story but this function is E5's shared
- * gate, so it must not inherit the hazard.
+ * @param value an extended ISO date or date-time, optionally with RFC 9557 annotations
+ * @returns the Temporal.PlainDate, in the computation calendar
  */
 export function parseCalendarDateValue(value) {
-    const match = calendarDate.exec(value);
-    if (!match) {
-        if (!plainDate.test(value)) {
-            throw new RangeError(`Not a valid GMT PlainDate string: ${value}`);
-        }
-        return Temporal.PlainDate.from(value);
+    // Temporal.PlainDate.from also takes objects and property bags; GMT reads strings only.
+    if (typeof value !== "string") {
+        throw new TypeError("A GMT calendar date must be a string");
     }
-    const [, year, month, day, calendarId, era] = match;
-    if (isEthiopicFamilyCalendar(calendarId)) {
-        return dateFromEthiopicFamilyFields(calendarId, {
-            year: era ? undefined : Number(year),
-            era,
-            eraYear: era ? Number(year) : undefined,
-            month: Number(month),
-            day: Number(day),
-        });
+    if (temporalStringLeapSecond.test(value)) {
+        throw new RangeError(`Leap seconds are not supported: ${value}`);
     }
-    // The regex captures GMT's own calendar identifier (e.g. "islamic-tabular"), which
-    // doesn't always match Temporal's id for the same calendar (e.g. "islamic-tbla") — an
-    // unrecognized id is passed through as-is so Temporal.PlainDate.from rejects it the
-    // same way it rejects any other unknown calendar identifier.
-    const temporalCalendarId = isCalendarSystem(calendarId)
-        ? temporalCalendarIds[calendarId]
-        : calendarId;
-    // A captured `;era=` suffix (only ever present for "japanese", the one remaining calendar
-    // whose plain `.year` doesn't reset at an era change) means `year` is an era-relative
-    // `eraYear`, not a proleptic year — Temporal needs `era`+`eraYear` together to resolve
-    // it back to the correct date.
-    const fields = era
-        ? { era, eraYear: Number(year), month: Number(month), day: Number(day) }
-        : { year: Number(year), month: Number(month), day: Number(day) };
-    return Temporal.PlainDate.from({ ...fields, calendar: temporalCalendarId }, { overflow: "reject" });
-}
-/**
- * Split a Temporal.PlainDate into GMT's calendar-annotated string halves: a bare ISO date with
- * an empty annotation for the "iso8601" calendar (GMT's existing default, unannotated), or the
- * calendar's own native year/month/day plus a `[u-ca=<identifier>]` annotation for any other.
- *
- * "japanese" is the one exception to "native year": Temporal's `.year` for it stays
- * proleptic across era changes (Meiji 1 and Reiwa 1 don't both read `1`), which would
- * contradict the era-based numbering the calendar is for — so it's tagged with `.eraYear`
- * and `;era=<name>` instead, both of which Temporal always populates for this calendar
- * (including for pre-Meiji dates, under a synthetic "japanese" era — see the README's
- * calendar-systems section for why GMT doesn't reject those unlike `@internationalized/date`).
- *
- * This function is never called with an Ethiopic-family ("ethiopic" /
- * "ethiopic-amete-alem" / "coptic") calendared date — those three format through
- * `ethiopicFamilyDateParts` in ethiopicFamilyCalendar.ts instead, which never touches
- * Temporal's own "ethiopic"/"coptic" calendar ids. See that file for why.
- */
-export function calendarDateParts(date) {
-    if (date.calendarId === "iso8601") {
-        return { date: date.toString(), annotation: "" };
+    const body = isoStringBody(value);
+    if (!plainDate.test(body) && !plainDateTime.test(body)) {
+        throw new RangeError(`Not an extended ISO 8601 date or date-time: ${value}`);
     }
-    const calendarId = calendarSystemIdFromTemporal(date.calendarId);
-    const isEraBased = calendarId === "japanese";
-    const year = String(isEraBased ? date.eraYear : date.year).padStart(4, "0");
-    const month = String(date.month).padStart(2, "0");
-    const day = String(date.day).padStart(2, "0");
-    const eraSuffix = isEraBased ? `;era=${date.era}` : "";
-    return {
-        date: `${year}-${month}-${day}`,
-        annotation: `[u-ca=${calendarId}${eraSuffix}]`,
-    };
-}
-/**
- * Format a Temporal.PlainDate as GMT's calendar-annotated string: a bare ISO string for
- * the "iso8601" calendar (GMT's existing default, unannotated), or the calendar's own
- * native year/month/day tagged with `[u-ca=<identifier>]` for any other calendar.
- *
- * See `calendarDateParts` (the shared primitive this concatenates) for the era handling and
- * the Ethiopic-family carve-out.
- */
-export function formatCalendarDate(date) {
-    const { date: datePart, annotation } = calendarDateParts(date);
-    return `${datePart}${annotation}`;
+    const date = Temporal.PlainDate.from(value);
+    const calendar = canonicalCalendarSystem(date.calendarId);
+    if (!calendar) {
+        throw new RangeError(`Unsupported calendar: ${date.calendarId}`);
+    }
+    return date.withCalendar(computationCalendarId(calendar));
 }

package/dist/internal/calendarSystemIds.d.ts

@@ -1,4 +1,28 @@
 import type { CalendarSystem } from "../types/index.js";
-export declare const temporalCalendarIds: Record<CalendarSystem, string>;
+/**
+ * Every `CalendarSystem`, by canonical calendar id: the CLDR `common/bcp47/calendar.xml` type,
+ * which is also what Temporal's `CanonicalizeCalendar` returns and what RFC 9557's `[u-ca=<id>]`
+ * carries. `"iso8601"` plus the Intl Era and Month Code proposal's `table-calendar-types` rows
+ * GMT supports (not `"chinese"` or `"dangi"`).
+ */
+export declare const calendarSystems: readonly CalendarSystem[];
+/** True when `value` is exactly a canonical `CalendarSystem` id (no alias, no case folding). */
 export declare function isCalendarSystem(value: string): value is CalendarSystem;
-export declare function calendarSystemIdFromTemporal(temporalId: string): CalendarSystem;
+/**
+ * The `CalendarSystem` a calendar id names, or `null` when GMT does not support it.
+ *
+ * Canonicalization is Temporal's (`CanonicalizeCalendar`: ASCII-lowercase, then the CLDR alias
+ * mapping, so `"ethiopic-amete-alem"` is `"ethioaa"` and `"islamicc"` is `"islamic-civil"`),
+ * asked of the polyfill rather than kept as a GMT copy of the alias table. Constructing a
+ * `PlainDate` reads no calendar fields, so this is safe for every calendar.
+ */
+export declare function canonicalCalendarSystem(id: string): CalendarSystem | null;
+/**
+ * The Temporal calendar a `CalendarSystem` computes in. The Ethiopic family (`"ethiopic"`,
+ * `"coptic"`) computes in `"ethioaa"`: polyfill 0.5.1 cannot read `"ethiopic"`/`"coptic"` fields
+ * under ICU >= 78, and the three calendars share months, days and arithmetic, differing only by a
+ * constant year offset (test262 `extreme-dates.js`: ethiopic = ethioaa − 5500, coptic = ethioaa −
+ * 5776 at both limits). Strings still carry the
+ * requested id; only the computation is routed.
+ */
+export declare function computationCalendarId(calendar: CalendarSystem): string;

package/dist/internal/calendarSystemIds.js

@@ -1,55 +1,61 @@
-// Maps GMT's public CalendarSystem identifiers to the Temporal/Intl calendar identifiers
-// they wrap. "gregorian" maps to "iso8601" (Temporal's default, era-free calendar) rather
-// than "gregory" (which carries BCE/CE eras) since GMT's existing unannotated ISO strings
-// are already iso8601-calendared — this keeps "gregorian" round-trips a no-op.
-//
-// "islamic-tabular" maps to Temporal's "islamic-tbla" id (its name for the same
-// arithmetic/astronomical-epoch tabular calendar). "islamic-umalqura" resolves through
-// Temporal's built-in Umm al-Qura implementation rather than a table GMT ports itself —
-// per E1's "no ported leap-year tables or arithmetic" precedent, the polyfill already
-// carries the correct tabulated/algorithmic data, so a GMT-owned copy would only add a
-// second, divergence-prone source of truth.
-//
-// "taiwan" maps to Temporal's "roc" id (Republic of China calendar — the same calendar
-// react-aria's TaiwanCalendar wraps under a different name). "japanese", "buddhist", and
-// "persian"/"indian" match Temporal's own ids directly.
-//
-// "ethiopic-amete-alem" maps to Temporal's "ethioaa" id (Ethiopic calendar anchored to the
-// Amete Alem/"Year of the World" epoch, ~5493 BCE — a single continuous era, never resets).
-// "ethiopic" and "coptic" match Temporal's own ids directly; both share the Ethiopic
-// family's 13-month structure (12 x 30 days + a 5/6-day Pagume/Nasie) but differ in epoch —
-// "ethiopic" additionally resets to the Amete Mihret/"Incarnation" era at its own epoch
-// (~AD 8), which is why it needs the same eraYear-based string handling as "japanese" (see
-// calendarDateString.ts's isEraBased).
-export const temporalCalendarIds = {
-    gregorian: "iso8601",
-    hebrew: "hebrew",
-    "islamic-civil": "islamic-civil",
-    "islamic-tabular": "islamic-tbla",
-    "islamic-umalqura": "islamic-umalqura",
-    japanese: "japanese",
-    buddhist: "buddhist",
-    taiwan: "roc",
-    persian: "persian",
-    indian: "indian",
-    ethiopic: "ethiopic",
-    "ethiopic-amete-alem": "ethioaa",
-    coptic: "coptic",
-};
+import { Temporal } from "@js-temporal/polyfill";
+/**
+ * Every `CalendarSystem`, by canonical calendar id: the CLDR `common/bcp47/calendar.xml` type,
+ * which is also what Temporal's `CanonicalizeCalendar` returns and what RFC 9557's `[u-ca=<id>]`
+ * carries. `"iso8601"` plus the Intl Era and Month Code proposal's `table-calendar-types` rows
+ * GMT supports (not `"chinese"` or `"dangi"`).
+ */
+export const calendarSystems = [
+    "iso8601",
+    "gregory",
+    "hebrew",
+    "islamic-civil",
+    "islamic-tbla",
+    "islamic-umalqura",
+    "japanese",
+    "buddhist",
+    "roc",
+    "persian",
+    "indian",
+    "ethiopic",
+    "ethioaa",
+    "coptic",
+];
+const calendarSystemSet = new Set(calendarSystems);
+/** True when `value` is exactly a canonical `CalendarSystem` id (no alias, no case folding). */
 export function isCalendarSystem(value) {
-    return value in temporalCalendarIds;
+    return calendarSystemSet.has(value);
 }
-// Reverse of temporalCalendarIds — needed because some GMT calendar identifiers (e.g.
-// "islamic-tabular") don't match Temporal's own id for the same calendar ("islamic-tbla"),
-// so a PlainDate's `calendarId` can't be used directly as GMT's string annotation.
-const gmtCalendarSystemIds = Object.fromEntries(Object.entries(temporalCalendarIds).map(([gmtId, temporalId]) => [
-    temporalId,
-    gmtId,
-]));
-export function calendarSystemIdFromTemporal(temporalId) {
-    const gmtId = gmtCalendarSystemIds[temporalId];
-    if (!gmtId) {
-        throw new Error(`Unsupported Temporal calendar id: ${temporalId}`);
+/**
+ * The `CalendarSystem` a calendar id names, or `null` when GMT does not support it.
+ *
+ * Canonicalization is Temporal's (`CanonicalizeCalendar`: ASCII-lowercase, then the CLDR alias
+ * mapping, so `"ethiopic-amete-alem"` is `"ethioaa"` and `"islamicc"` is `"islamic-civil"`),
+ * asked of the polyfill rather than kept as a GMT copy of the alias table. Constructing a
+ * `PlainDate` reads no calendar fields, so this is safe for every calendar.
+ */
+export function canonicalCalendarSystem(id) {
+    if (typeof id !== "string" || id.length === 0) {
+        return null;
     }
-    return gmtId;
+    try {
+        const canonical = new Temporal.PlainDate(1970, 1, 1, id).calendarId;
+        return isCalendarSystem(canonical) ? canonical : null;
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * The Temporal calendar a `CalendarSystem` computes in. The Ethiopic family (`"ethiopic"`,
+ * `"coptic"`) computes in `"ethioaa"`: polyfill 0.5.1 cannot read `"ethiopic"`/`"coptic"` fields
+ * under ICU >= 78, and the three calendars share months, days and arithmetic, differing only by a
+ * constant year offset (test262 `extreme-dates.js`: ethiopic = ethioaa − 5500, coptic = ethioaa −
+ * 5776 at both limits). Strings still carry the
+ * requested id; only the computation is routed.
+ */
+export function computationCalendarId(calendar) {
+    return calendar === "ethiopic" || calendar === "coptic"
+        ? "ethioaa"
+        : calendar;
 }

package/dist/internal/calendarValueOfDate.d.ts

@@ -1,22 +1,20 @@
 import type { CalendarSystem } from "../types/index.js";
 /**
- * Determine which CalendarSystem a GMT PlainDate string is expressed in: `"gregorian"` for a
- * bare (non-annotated) string, the tagged CalendarSystem for a calendar-annotated string (as
- * produced by `convertDateToCalendar`), or `null` when the annotation names an unrecognized
- * calendar identifier.
+ * Determine which CalendarSystem a GMT PlainDate string is expressed in: `"iso8601"` for a string
+ * with no `u-ca` annotation, the canonical id of the calendar Temporal reads from the annotations
+ * otherwise (`[u-ca=HEBREW]` is `"hebrew"`, `[u-ca=ethiopic-amete-alem]` is `"ethioaa"`, and in
+ * `[u-ca=hebrew][u-ca=roc]` the first annotation wins), or `null` when the annotations do not
+ * parse or GMT does not support that calendar.
  *
- * Does not itself validate overall shape or field values — pair with `parseCalendarDateValue`
- * (which throws on invalid input) for full validation. Callers are expected to have already
- * confirmed `value` is valid (e.g. via `isValidCalendarDate`) before relying on this.
- *
- * Part of E5 (issue #78)'s calendar-aware `plain/` gate — see the E5 decisions of record for
- * why calendar-system awareness is confined to `plain/` `PlainDate` values (D1).
+ * Does not itself validate the date — pair with `parseCalendarDateValue` (which throws on invalid
+ * input) for full validation. Callers are expected to have already confirmed `value` is valid
+ * (e.g. via `isValidCalendarDate`) before relying on this.
  */
 export declare function calendarSystemOfDateValue(value: string): CalendarSystem | null;
 /**
  * N-ary generalization of `calendarSystemOfDateValue` for list-form functions
  * (`mergeIntervalsDate`, `intervalXorAllDate`, `intervalSplitAtDate`'s `points`): returns the
- * shared CalendarSystem when every value carries the same tag, or `null` on any mismatch or
- * unrecognized identifier. An empty list is treated as `"gregorian"` (the identity/no-op case).
+ * shared CalendarSystem when every value names the same calendar, or `null` on any mismatch or
+ * unsupported identifier. An empty list is treated as `"iso8601"` (the identity/no-op case).
  */
 export declare function calendarOfAllDateValues(values: readonly string[]): CalendarSystem | null;

package/dist/internal/calendarValueOfDate.js

@@ -1,35 +1,37 @@
-import { calendarDate } from "../regex/index.js";
-import { isCalendarSystem } from "./calendarSystemIds.js";
+import { Temporal } from "@js-temporal/polyfill";
+import { canonicalCalendarSystem } from "./calendarSystemIds.js";
+import { hasCalendarAnnotation } from "./hasCalendarAnnotation.js";
 /**
- * Determine which CalendarSystem a GMT PlainDate string is expressed in: `"gregorian"` for a
- * bare (non-annotated) string, the tagged CalendarSystem for a calendar-annotated string (as
- * produced by `convertDateToCalendar`), or `null` when the annotation names an unrecognized
- * calendar identifier.
+ * Determine which CalendarSystem a GMT PlainDate string is expressed in: `"iso8601"` for a string
+ * with no `u-ca` annotation, the canonical id of the calendar Temporal reads from the annotations
+ * otherwise (`[u-ca=HEBREW]` is `"hebrew"`, `[u-ca=ethiopic-amete-alem]` is `"ethioaa"`, and in
+ * `[u-ca=hebrew][u-ca=roc]` the first annotation wins), or `null` when the annotations do not
+ * parse or GMT does not support that calendar.
  *
- * Does not itself validate overall shape or field values — pair with `parseCalendarDateValue`
- * (which throws on invalid input) for full validation. Callers are expected to have already
- * confirmed `value` is valid (e.g. via `isValidCalendarDate`) before relying on this.
- *
- * Part of E5 (issue #78)'s calendar-aware `plain/` gate — see the E5 decisions of record for
- * why calendar-system awareness is confined to `plain/` `PlainDate` values (D1).
+ * Does not itself validate the date — pair with `parseCalendarDateValue` (which throws on invalid
+ * input) for full validation. Callers are expected to have already confirmed `value` is valid
+ * (e.g. via `isValidCalendarDate`) before relying on this.
  */
 export function calendarSystemOfDateValue(value) {
-    const match = calendarDate.exec(value);
-    if (!match) {
-        return "gregorian";
+    if (!hasCalendarAnnotation(value)) {
+        return "iso8601";
+    }
+    try {
+        return canonicalCalendarSystem(Temporal.PlainDate.from(value).calendarId);
+    }
+    catch {
+        return null;
     }
-    const [, , , , calendarId] = match;
-    return isCalendarSystem(calendarId) ? calendarId : null;
 }
 /**
  * N-ary generalization of `calendarSystemOfDateValue` for list-form functions
  * (`mergeIntervalsDate`, `intervalXorAllDate`, `intervalSplitAtDate`'s `points`): returns the
- * shared CalendarSystem when every value carries the same tag, or `null` on any mismatch or
- * unrecognized identifier. An empty list is treated as `"gregorian"` (the identity/no-op case).
+ * shared CalendarSystem when every value names the same calendar, or `null` on any mismatch or
+ * unsupported identifier. An empty list is treated as `"iso8601"` (the identity/no-op case).
  */
 export function calendarOfAllDateValues(values) {
     if (values.length === 0) {
-        return "gregorian";
+        return "iso8601";
     }
     const first = calendarSystemOfDateValue(values[0]);
     if (!first) {

package/dist/internal/calendarValueOfZoned.d.ts

@@ -1,22 +1,19 @@
 import type { CalendarSystem } from "../types/index.js";
 /**
- * Determine which CalendarSystem a GMT ZonedDateTime string is expressed in: `"gregorian"` for a
- * bare (non-annotated) ISO zoned string, the tagged CalendarSystem for a GMT calendar-annotated
- * zoned string (as produced by `convertZonedToCalendar`), or `null` when the annotation names an
- * unrecognized calendar identifier.
+ * Determine which CalendarSystem a GMT ZonedDateTime string is expressed in: `"iso8601"` for a
+ * string with no `u-ca` annotation, the canonical id of the calendar Temporal reads from the
+ * annotations otherwise (as `convertZonedToCalendar` writes them; in `[u-ca=hebrew][u-ca=roc]` the
+ * first annotation wins), or `null` when the string does not parse or GMT does not support that
+ * calendar.
  *
- * Kept as its own file rather than an overload of `calendarValueOfDate.ts` because the two differ
- * on both axes that matter: the regex (zoned carries a time, an offset and a `[timeZone]`
- * segment) and the non-matching fallback. `calendarSystemOfDateValue` reports `"gregorian"` for
- * ANY non-match, which is safe there because `plain/`'s only annotated shape is the one its regex
- * accepts. In `zoned/` a non-matching string may still carry `[u-ca=...]` — Temporal's own
- * RFC 9557 ordering, or a wrong-ordered GMT string — and calling either of those `"gregorian"`
- * would hand a caller a Gregorian answer for a string that visibly asked for something else. Those
- * fail closed with `null` instead.
+ * Kept as its own file rather than an overload of `calendarValueOfDate.ts` because the parse
+ * differs: a zoned string goes to `zonedDateTimeFrom`. The offset is ignored for this read (the
+ * calendar does not depend on it), so a caller's own `offset` option still decides whether the
+ * value itself is accepted.
  *
- * Does not itself validate overall shape or field values — pair with `parseCalendarZonedValue`
- * (which throws on invalid input) for full validation. Callers are expected to have already
- * confirmed `value` is valid (e.g. via `isValidCalendarZonedDateTime`) before relying on this.
+ * Does not itself validate the value — pair with `parseCalendarZonedValue` (which throws on
+ * invalid input) for full validation. Callers are expected to have already confirmed `value` is
+ * valid (e.g. via `isValidCalendarZonedDateTime`) before relying on this.
  *
  * Part of E7 (issue #152)'s calendar-aware `zoned/` gate.
  */
@@ -25,8 +22,8 @@ export declare function calendarSystemOfZonedValue(value: string): CalendarSyste
  * N-ary generalization of `calendarSystemOfZonedValue` for list-form functions
  * (`mergeIntervalsZoned`, `intervalXorAllZoned`, `intervalSplitAtZoned`'s `points`, and the
  * four-endpoint pairwise set operations): returns the shared CalendarSystem when every value
- * carries the same tag, or `null` on any mismatch or unrecognized identifier. An empty list is
- * treated as `"gregorian"` (the identity/no-op case).
+ * names the same calendar, or `null` on any mismatch or unsupported identifier. An empty list is
+ * treated as `"iso8601"` (the identity/no-op case).
  *
  * This is E7's D4-zoned reject gate for the eight value-returning interval set operations. A
  * "winning endpoint's tag survives" policy was considered and rejected: four of the eight return

package/dist/internal/calendarValueOfZoned.js

@@ -1,41 +1,41 @@
-import { calendarZonedDateTime } from "../regex/index.js";
-import { isCalendarSystem } from "./calendarSystemIds.js";
+import { canonicalCalendarSystem } from "./calendarSystemIds.js";
 import { hasCalendarAnnotation } from "./hasCalendarAnnotation.js";
+import { zonedDateTimeFrom } from "./zonedWallClock.js";
 /**
- * Determine which CalendarSystem a GMT ZonedDateTime string is expressed in: `"gregorian"` for a
- * bare (non-annotated) ISO zoned string, the tagged CalendarSystem for a GMT calendar-annotated
- * zoned string (as produced by `convertZonedToCalendar`), or `null` when the annotation names an
- * unrecognized calendar identifier.
+ * Determine which CalendarSystem a GMT ZonedDateTime string is expressed in: `"iso8601"` for a
+ * string with no `u-ca` annotation, the canonical id of the calendar Temporal reads from the
+ * annotations otherwise (as `convertZonedToCalendar` writes them; in `[u-ca=hebrew][u-ca=roc]` the
+ * first annotation wins), or `null` when the string does not parse or GMT does not support that
+ * calendar.
  *
- * Kept as its own file rather than an overload of `calendarValueOfDate.ts` because the two differ
- * on both axes that matter: the regex (zoned carries a time, an offset and a `[timeZone]`
- * segment) and the non-matching fallback. `calendarSystemOfDateValue` reports `"gregorian"` for
- * ANY non-match, which is safe there because `plain/`'s only annotated shape is the one its regex
- * accepts. In `zoned/` a non-matching string may still carry `[u-ca=...]` — Temporal's own
- * RFC 9557 ordering, or a wrong-ordered GMT string — and calling either of those `"gregorian"`
- * would hand a caller a Gregorian answer for a string that visibly asked for something else. Those
- * fail closed with `null` instead.
+ * Kept as its own file rather than an overload of `calendarValueOfDate.ts` because the parse
+ * differs: a zoned string goes to `zonedDateTimeFrom`. The offset is ignored for this read (the
+ * calendar does not depend on it), so a caller's own `offset` option still decides whether the
+ * value itself is accepted.
  *
- * Does not itself validate overall shape or field values — pair with `parseCalendarZonedValue`
- * (which throws on invalid input) for full validation. Callers are expected to have already
- * confirmed `value` is valid (e.g. via `isValidCalendarZonedDateTime`) before relying on this.
+ * Does not itself validate the value — pair with `parseCalendarZonedValue` (which throws on
+ * invalid input) for full validation. Callers are expected to have already confirmed `value` is
+ * valid (e.g. via `isValidCalendarZonedDateTime`) before relying on this.
  *
  * Part of E7 (issue #152)'s calendar-aware `zoned/` gate.
  */
 export function calendarSystemOfZonedValue(value) {
-    const match = calendarZonedDateTime.exec(value);
-    if (!match) {
-        return hasCalendarAnnotation(value) ? null : "gregorian";
+    if (!hasCalendarAnnotation(value)) {
+        return "iso8601";
+    }
+    try {
+        return canonicalCalendarSystem(zonedDateTimeFrom(value, { offset: "ignore" }).calendarId);
+    }
+    catch {
+        return null;
     }
-    const [, , , , , , calendarId] = match;
-    return isCalendarSystem(calendarId) ? calendarId : null;
 }
 /**
  * N-ary generalization of `calendarSystemOfZonedValue` for list-form functions
  * (`mergeIntervalsZoned`, `intervalXorAllZoned`, `intervalSplitAtZoned`'s `points`, and the
  * four-endpoint pairwise set operations): returns the shared CalendarSystem when every value
- * carries the same tag, or `null` on any mismatch or unrecognized identifier. An empty list is
- * treated as `"gregorian"` (the identity/no-op case).
+ * names the same calendar, or `null` on any mismatch or unsupported identifier. An empty list is
+ * treated as `"iso8601"` (the identity/no-op case).
  *
  * This is E7's D4-zoned reject gate for the eight value-returning interval set operations. A
  * "winning endpoint's tag survives" policy was considered and rejected: four of the eight return
@@ -46,7 +46,7 @@ export function calendarSystemOfZonedValue(value) {
  */
 export function calendarOfAllZonedValues(values) {
     if (values.length === 0) {
-        return "gregorian";
+        return "iso8601";
     }
     const first = calendarSystemOfZonedValue(values[0]);
     if (!first) {

package/dist/internal/calendarZonedPairPolicy.d.ts

@@ -7,25 +7,18 @@ export interface CalendarZonedPair {
 }
 /**
  * Parse two GMT ZonedDateTime values for calendar-unit arithmetic (diff, count, length,
- * split-by-unit): measure in the endpoints' shared calendar when both match, fall back to
- * Gregorian/ISO otherwise, rather than rejecting outright. The zoned sibling of
- * `calendarDatePairPolicy.ts`'s `parseCalendarDatePairForArithmetic` (E5 decision D5).
+ * split-by-unit): both must name the same calendar, which the pair is measured in. The zoned
+ * sibling of `calendarDatePairPolicy.ts`'s `parseCalendarDatePairForArithmetic`.
  *
- * The fallback is MORE load-bearing here than in `plain/`, not less.
- * `Temporal.PlainDate.prototype.until` throws across mismatched calendars only for date units;
- * `Temporal.ZonedDateTime.prototype.until` throws for EVERY `largestUnit` — verified, including
- * `"hour"` and `"nanosecond"`. Without this policy, `diffZoned(hebrewValue, islamicValue,
- * "hours")` would return `null` for a question that has nothing to do with either calendar.
+ * Follows TC39 Temporal's `DifferenceTemporalZonedDateTime`: when `CalendarEquals` is false it
+ * throws a RangeError, for every `largestUnit`, `"hour"` and `"nanosecond"` included (native
+ * Temporal agrees). Calendars are compared by their canonical id; a bare ISO string names
+ * `iso8601`. Callers catch the throw and return their sentinel. (Before 1.16.0 the pair fell
+ * back to ISO; ordering-only functions still accept mixed calendars, because
+ * `Temporal.ZonedDateTime.compare` has no calendar check.)
  *
- * **Consume the returned `a`/`b`, never the values you parsed them from.** The returned operands
- * are already normalized to the resolved calendar, and every downstream use — including a
- * `Temporal.Duration.prototype.total` `relativeTo` anchor — has to be the normalized one. Feeding
- * a raw calendar-tagged operand to `relativeTo` while measuring in ISO does NOT throw; it returns
- * a plausible-looking wrong number (verified: 12.586… where the correct ISO answer is 12.5666…
- * and the correct Hebrew answer is 13), which no sanity check would catch.
- *
- * Throws if either value fails to parse as a valid GMT ZonedDateTime string — callers are
- * expected to have already validated both values (e.g. via `isValidCalendarZonedDateTime`) before
- * calling this, consistent with GMT's existing gate-then-parse-inside-try structure.
+ * Throws if either value fails to parse as a valid GMT ZonedDateTime string, or if the calendars
+ * differ — callers validate both values first (e.g. via `isValidCalendarZonedDateTime`) and wrap
+ * this in try-catch, consistent with GMT's gate-then-parse-inside-try structure.
  */
 export declare function parseCalendarZonedPairForArithmetic(aValue: string, bValue: string): CalendarZonedPair;