@northguild/gmt 1.14.2

package/dist/zoned/interval/intervalEngulfsZoned.d.ts

@@ -0,0 +1,30 @@
+/**
+ * Return true when interval B is fully contained within interval A — every instant of B
+ * falls within A.
+ *
+ * - Uses `Temporal.Instant.compare` for comparison (via `.toInstant()`).
+ * - Equivalent to 4-argument `intervalContainsZoned(aStart, aEnd, bStart, bEnd)`.
+ * - Returns `false` if either interval is invalid (`start > end`).
+ * - Returns `false` on invalid input (wrong type, malformed strings, leap seconds).
+ * - **Accepts mixed calendar systems** (E7's D4-zoned, issue #152): both bare ISO zoned strings
+ *   and GMT calendar-annotated ones (`"5784-06-15T14:30:00-05:00[u-ca=hebrew][America/New_York]"`),
+ *   and the two endpoints need not agree on a calendar. Ordering is calendar-independent —
+ *   verified that `Temporal.Instant` carries no calendar field at all and that
+ *   `Instant.compare`/`ZonedDateTime.compare` both return `0` for the same instant expressed in
+ *   hebrew, islamic-civil, japanese and iso8601.
+ * - Still rejects Temporal's own `[timeZone][u-ca=...]` RFC 9557 ordering, which reads GMT's
+ *   calendar-native digits as ISO digits — see `regex/calendar-zoned-date-time.ts`.
+ *
+ * @param aStart ISO 8601 zoned datetime string for the outer interval start
+ * @param aEnd ISO 8601 zoned datetime string for the outer interval end
+ * @param bStart ISO 8601 zoned datetime string for the inner interval start
+ * @param bEnd ISO 8601 zoned datetime string for the inner interval end
+ * @returns true if B is fully contained in A, or false on invalid input
+ *
+ * @example intervalEngulfsZoned("2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]", "2024-06-01T12:00:00+00:00[UTC]", "2024-07-01T13:00:00+00:00[UTC]") // true
+ * @example intervalEngulfsZoned("2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]", "2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]") // true (equal intervals)
+ * @example intervalEngulfsZoned("2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]", "2024-01-01T09:00:00+00:00[UTC]", "2024-06-30T12:00:00+00:00[UTC]") // true
+ * @example intervalEngulfsZoned("2024-06-01T12:00:00+00:00[UTC]", "2024-07-01T13:00:00+00:00[UTC]", "2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]") // false
+ * @example intervalEngulfsZoned("invalid", "2024-12-31T17:00:00+00:00[UTC]", "2024-06-01T12:00:00+00:00[UTC]", "2024-07-01T13:00:00+00:00[UTC]") // false
+ */
+export declare function intervalEngulfsZoned(aStart: string, aEnd: string, bStart: string, bEnd: string): boolean;

package/dist/zoned/interval/intervalEngulfsZoned.js

@@ -0,0 +1,65 @@
+import { Temporal } from "@js-temporal/polyfill";
+import { parseCalendarZonedValue } from "../../internal/index.js";
+import { isValidCalendarZonedDateTime } from "../validate/index.js";
+/**
+ * Return true when interval B is fully contained within interval A — every instant of B
+ * falls within A.
+ *
+ * - Uses `Temporal.Instant.compare` for comparison (via `.toInstant()`).
+ * - Equivalent to 4-argument `intervalContainsZoned(aStart, aEnd, bStart, bEnd)`.
+ * - Returns `false` if either interval is invalid (`start > end`).
+ * - Returns `false` on invalid input (wrong type, malformed strings, leap seconds).
+ * - **Accepts mixed calendar systems** (E7's D4-zoned, issue #152): both bare ISO zoned strings
+ *   and GMT calendar-annotated ones (`"5784-06-15T14:30:00-05:00[u-ca=hebrew][America/New_York]"`),
+ *   and the two endpoints need not agree on a calendar. Ordering is calendar-independent —
+ *   verified that `Temporal.Instant` carries no calendar field at all and that
+ *   `Instant.compare`/`ZonedDateTime.compare` both return `0` for the same instant expressed in
+ *   hebrew, islamic-civil, japanese and iso8601.
+ * - Still rejects Temporal's own `[timeZone][u-ca=...]` RFC 9557 ordering, which reads GMT's
+ *   calendar-native digits as ISO digits — see `regex/calendar-zoned-date-time.ts`.
+ *
+ * @param aStart ISO 8601 zoned datetime string for the outer interval start
+ * @param aEnd ISO 8601 zoned datetime string for the outer interval end
+ * @param bStart ISO 8601 zoned datetime string for the inner interval start
+ * @param bEnd ISO 8601 zoned datetime string for the inner interval end
+ * @returns true if B is fully contained in A, or false on invalid input
+ *
+ * @example intervalEngulfsZoned("2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]", "2024-06-01T12:00:00+00:00[UTC]", "2024-07-01T13:00:00+00:00[UTC]") // true
+ * @example intervalEngulfsZoned("2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]", "2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]") // true (equal intervals)
+ * @example intervalEngulfsZoned("2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]", "2024-01-01T09:00:00+00:00[UTC]", "2024-06-30T12:00:00+00:00[UTC]") // true
+ * @example intervalEngulfsZoned("2024-06-01T12:00:00+00:00[UTC]", "2024-07-01T13:00:00+00:00[UTC]", "2024-01-01T09:00:00+00:00[UTC]", "2024-12-31T17:00:00+00:00[UTC]") // false
+ * @example intervalEngulfsZoned("invalid", "2024-12-31T17:00:00+00:00[UTC]", "2024-06-01T12:00:00+00:00[UTC]", "2024-07-01T13:00:00+00:00[UTC]") // false
+ */
+export function intervalEngulfsZoned(aStart, aEnd, bStart, bEnd) {
+    // One gate for all four endpoints: `isValidCalendarZonedDateTime` already covers non-strings,
+    // empty strings, leap seconds (which Temporal would otherwise silently clamp to :59), unknown
+    // zones and Temporal's forbidden segment ordering — and, unlike `isValidZonedDateTime`, accepts
+    // GMT's calendar-annotated grammar.
+    if (!isValidCalendarZonedDateTime(aStart) ||
+        !isValidCalendarZonedDateTime(aEnd) ||
+        !isValidCalendarZonedDateTime(bStart) ||
+        !isValidCalendarZonedDateTime(bEnd)) {
+        return false;
+    }
+    try {
+        const aSZdt = parseCalendarZonedValue(aStart);
+        const aEZdt = parseCalendarZonedValue(aEnd);
+        const bSZdt = parseCalendarZonedValue(bStart);
+        const bEZdt = parseCalendarZonedValue(bEnd);
+        const aS = aSZdt.toInstant();
+        const aE = aEZdt.toInstant();
+        const bS = bSZdt.toInstant();
+        const bE = bEZdt.toInstant();
+        if (Temporal.Instant.compare(aS, aE) > 0) {
+            return false;
+        }
+        if (Temporal.Instant.compare(bS, bE) > 0) {
+            return false;
+        }
+        return (Temporal.Instant.compare(aS, bS) <= 0 &&
+            Temporal.Instant.compare(bE, aE) <= 0);
+    }
+    catch {
+        return false;
+    }
+}

package/dist/zoned/interval/intervalFromDurationZoned.d.ts

@@ -0,0 +1,45 @@
+import type { Disambiguation, Offset, Overflow } from "../../types/index.js";
+/**
+ * Construct a zoned interval from a single point plus an ISO 8601 duration, anchored at either end.
+ *
+ * - `anchor: "start"` treats `value` as the interval start and adds `duration` to get the end.
+ * - `anchor: "end"` treats `value` as the interval end and subtracts `duration` to get the start.
+ * - Uses `Temporal.ZonedDateTime.prototype.add`/`.subtract`, so calendar units (years/months/weeks)
+ *   resolve against `value` itself — no separate `relativeTo` is needed.
+ * - `disambiguation` controls DST resolution ONLY when the arithmetic result lands on an ambiguous
+ *   local time from a fall-back (DST-end) overlap: "compatible" (default), "earlier", "later", or
+ *   "reject" (returns null). Mirrors `addZoned`'s exact semantics — has no effect on a spring-forward
+ *   (DST-start) gap landing, which Temporal's arithmetic always resolves before disambiguation runs.
+ * - `offset` is accepted for API consistency with `addZoned` but has **no effect here** for the same
+ *   reason documented there: the disambiguation rebuild has no stored offset to prefer/use/ignore/reject.
+ * - A negative `duration` (e.g. `"-P1D"`) can invert the computed span; returns null when that
+ *   happens, mirroring `intervalIntersectionZoned`'s `start > end` rejection.
+ * - `overflow` ("constrain" (default) | "reject") controls out-of-range results, e.g. adding 1 month
+ *   to Jan 31: "constrain" clamps to Feb 29/28, "reject" returns null.
+ * - Accepts a GMT calendar-annotated zoned string (as produced by `convertZonedToCalendar`) as
+ *   well as a bare ISO one — E7 (issue #152). Calendar units in `duration` resolve against that
+ *   calendar, and both returned endpoints are re-derived in it via `formatZonedInCalendar`. There
+ *   is only ONE calendar-tagged input here, so no D5 pair policy applies — nothing can mismatch.
+ * - Returns null on invalid input (unparseable `value`, invalid `duration`, or an `anchor` other
+ *   than `"start"`/`"end"`).
+ *
+ * @param value ISO 8601 zoned datetime string, optionally calendar-annotated
+ * @param duration ISO 8601 duration string
+ * @param anchor "start" | "end" — which endpoint `value` represents
+ * @param options optional: disambiguation ("compatible" | "earlier" | "later" | "reject"), offset ("prefer" | "use" | "ignore" | "reject" — accepted but inert, see above), overflow ("constrain" | "reject")
+ * @returns `{ start, end }` with the constructed span, or null on invalid input
+ *
+ * @example intervalFromDurationZoned("2024-01-01T00:00:00+00:00[UTC]", "P1D", "start") // { start: "2024-01-01T00:00:00+00:00[UTC]", end: "2024-01-02T00:00:00+00:00[UTC]" }
+ * @example intervalFromDurationZoned("2024-01-02T00:00:00+00:00[UTC]", "P1D", "end") // { start: "2024-01-01T00:00:00+00:00[UTC]", end: "2024-01-02T00:00:00+00:00[UTC]" }
+ * @example intervalFromDurationZoned("2024-11-02T01:30:00-04:00[America/New_York]", "P1D", "start", { disambiguation: "later" }) // { start: "2024-11-02T01:30:00-04:00[America/New_York]", end: "2024-11-03T01:30:00-05:00[America/New_York]" } (fall-back overlap resolved; default "compatible" would return the -04:00 instant instead)
+ * @example intervalFromDurationZoned("2024-01-31T12:00:00-05:00[America/New_York]", "P1M", "start", { overflow: "reject" }) // null
+ * @example intervalFromDurationZoned("invalid", "P1D", "start") // null
+ */
+export declare function intervalFromDurationZoned(value: string, duration: string, anchor: "start" | "end", options?: {
+    disambiguation?: Disambiguation;
+    offset?: Offset;
+    overflow?: Overflow;
+}): {
+    start: string;
+    end: string;
+} | null;

package/dist/zoned/interval/intervalFromDurationZoned.js

@@ -0,0 +1,85 @@
+import { Temporal } from "@js-temporal/polyfill";
+import { isValidDuration } from "../../duration/validate/index.js";
+import { calendarSystemOfZonedValue, formatZonedInCalendar, parseCalendarZonedValue, resolveOverflow, } from "../../internal/index.js";
+import { isValidCalendarZonedDateTime } from "../validate/index.js";
+/**
+ * Construct a zoned interval from a single point plus an ISO 8601 duration, anchored at either end.
+ *
+ * - `anchor: "start"` treats `value` as the interval start and adds `duration` to get the end.
+ * - `anchor: "end"` treats `value` as the interval end and subtracts `duration` to get the start.
+ * - Uses `Temporal.ZonedDateTime.prototype.add`/`.subtract`, so calendar units (years/months/weeks)
+ *   resolve against `value` itself — no separate `relativeTo` is needed.
+ * - `disambiguation` controls DST resolution ONLY when the arithmetic result lands on an ambiguous
+ *   local time from a fall-back (DST-end) overlap: "compatible" (default), "earlier", "later", or
+ *   "reject" (returns null). Mirrors `addZoned`'s exact semantics — has no effect on a spring-forward
+ *   (DST-start) gap landing, which Temporal's arithmetic always resolves before disambiguation runs.
+ * - `offset` is accepted for API consistency with `addZoned` but has **no effect here** for the same
+ *   reason documented there: the disambiguation rebuild has no stored offset to prefer/use/ignore/reject.
+ * - A negative `duration` (e.g. `"-P1D"`) can invert the computed span; returns null when that
+ *   happens, mirroring `intervalIntersectionZoned`'s `start > end` rejection.
+ * - `overflow` ("constrain" (default) | "reject") controls out-of-range results, e.g. adding 1 month
+ *   to Jan 31: "constrain" clamps to Feb 29/28, "reject" returns null.
+ * - Accepts a GMT calendar-annotated zoned string (as produced by `convertZonedToCalendar`) as
+ *   well as a bare ISO one — E7 (issue #152). Calendar units in `duration` resolve against that
+ *   calendar, and both returned endpoints are re-derived in it via `formatZonedInCalendar`. There
+ *   is only ONE calendar-tagged input here, so no D5 pair policy applies — nothing can mismatch.
+ * - Returns null on invalid input (unparseable `value`, invalid `duration`, or an `anchor` other
+ *   than `"start"`/`"end"`).
+ *
+ * @param value ISO 8601 zoned datetime string, optionally calendar-annotated
+ * @param duration ISO 8601 duration string
+ * @param anchor "start" | "end" — which endpoint `value` represents
+ * @param options optional: disambiguation ("compatible" | "earlier" | "later" | "reject"), offset ("prefer" | "use" | "ignore" | "reject" — accepted but inert, see above), overflow ("constrain" | "reject")
+ * @returns `{ start, end }` with the constructed span, or null on invalid input
+ *
+ * @example intervalFromDurationZoned("2024-01-01T00:00:00+00:00[UTC]", "P1D", "start") // { start: "2024-01-01T00:00:00+00:00[UTC]", end: "2024-01-02T00:00:00+00:00[UTC]" }
+ * @example intervalFromDurationZoned("2024-01-02T00:00:00+00:00[UTC]", "P1D", "end") // { start: "2024-01-01T00:00:00+00:00[UTC]", end: "2024-01-02T00:00:00+00:00[UTC]" }
+ * @example intervalFromDurationZoned("2024-11-02T01:30:00-04:00[America/New_York]", "P1D", "start", { disambiguation: "later" }) // { start: "2024-11-02T01:30:00-04:00[America/New_York]", end: "2024-11-03T01:30:00-05:00[America/New_York]" } (fall-back overlap resolved; default "compatible" would return the -04:00 instant instead)
+ * @example intervalFromDurationZoned("2024-01-31T12:00:00-05:00[America/New_York]", "P1M", "start", { overflow: "reject" }) // null
+ * @example intervalFromDurationZoned("invalid", "P1D", "start") // null
+ */
+export function intervalFromDurationZoned(value, duration, anchor, options) {
+    if (!isValidCalendarZonedDateTime(value)) {
+        return null;
+    }
+    if (!isValidDuration(duration)) {
+        return null;
+    }
+    if (anchor !== "start" && anchor !== "end") {
+        return null;
+    }
+    const disambiguation = options?.disambiguation ?? "compatible";
+    const offset = options?.offset ?? "ignore";
+    const overflow = resolveOverflow(options?.overflow);
+    try {
+        const calendar = calendarSystemOfZonedValue(value);
+        if (!calendar) {
+            return null;
+        }
+        const point = parseCalendarZonedValue(value);
+        const dur = Temporal.Duration.from(duration);
+        const rawOther = anchor === "start"
+            ? point.add(dur, { overflow })
+            : point.subtract(dur, { overflow });
+        // The calendar MUST be stripped before this rebuild string is composed (E7 risk R1) — see
+        // `addZoned`'s equivalent comment. A calendared `.toPlainDateTime().toString()` already
+        // carries Temporal's own `[u-ca=...]` annotation, so appending `[${timeZoneId}]` produces
+        // GMT's forbidden segment ordering and `Temporal.ZonedDateTime.from` rejects it, silently
+        // degrading every non-"compatible" disambiguation to null.
+        const other = disambiguation === "compatible"
+            ? rawOther
+            : Temporal.ZonedDateTime.from(`${rawOther.withCalendar("iso8601").toPlainDateTime().toString()}[${rawOther.timeZoneId}]`, { disambiguation, offset }).withCalendar(rawOther.calendarId);
+        const start = anchor === "start" ? point : other;
+        const end = anchor === "start" ? other : point;
+        if (Temporal.ZonedDateTime.compare(start, end) > 0) {
+            return null;
+        }
+        return {
+            start: formatZonedInCalendar(start, calendar),
+            end: formatZonedInCalendar(end, calendar),
+        };
+    }
+    catch {
+        return null;
+    }
+}

package/dist/zoned/interval/intervalIntersectionZoned.d.ts

@@ -0,0 +1,36 @@
+/**
+ * Return the overlapping span of two zoned intervals, or null when they do not overlap.
+ *
+ * - Uses `Temporal.ZonedDateTime.compare` for comparison (same instant semantics).
+ * - Adjacent intervals (e.g. `aEnd === bStart`) share one instant and DO overlap.
+ * - Returns `null` if either interval is invalid (`start > end`).
+ * - Returns `null` on invalid input (wrong type, malformed strings, leap seconds).
+ * - Accepts GMT calendar-annotated zoned strings (as produced by `convertZonedToCalendar`) as
+ *   well as bare ISO ones — E7 (issue #152) — but **rejects a mismatched pair**: every endpoint
+ *   must name the same calendar system (E7's D4-zoned). Unlike the ordering functions, this one
+ *   returns a *value* the caller reads back as a datetime, and there is no principled way to pick
+ *   one endpoint's calendar as the answer's. Rejection also keeps a uniform policy across all
+ *   eight value-returning zoned set operations, four of which return arrays — a per-element
+ *   "winner's tag" would produce a result set whose members disagree about which calendar they
+ *   are in. (`intervalUnionZoned`'s existing "winning endpoint's *time zone* wins" is not
+ *   precedent: the zone is a property of the surviving point, the calendar is a property of the
+ *   answer.) A mismatch returns the sentinel.
+ * - Output boundaries are re-derived in the resolved calendar via `formatZonedInCalendar`, never
+ *   copied from an input string (E7's D7-zoned).
+ * - Still rejects Temporal's own `[timeZone][u-ca=...]` RFC 9557 ordering — see
+ *   `regex/calendar-zoned-date-time.ts`.
+ *
+ * @param aStart ISO 8601 zoned datetime string for the first interval start
+ * @param aEnd ISO 8601 zoned datetime string for the first interval end
+ * @param bStart ISO 8601 zoned datetime string for the second interval start
+ * @param bEnd ISO 8601 zoned datetime string for the second interval end
+ * @returns `{ start, end }` with the overlapping span, or null on invalid input / no overlap
+ *
+ * @example intervalIntersectionZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-06-30T23:59:59+00:00[UTC]", "2024-04-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // { start: "2024-04-01T00:00:00+00:00[UTC]", end: "2024-06-30T23:59:59+00:00[UTC]" }
+ * @example intervalIntersectionZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-06-30T23:59:59+00:00[UTC]", "2024-07-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // null
+ * @example intervalIntersectionZoned("invalid", "2024-06-30T23:59:59+00:00[UTC]", "2024-04-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // null
+ */
+export declare function intervalIntersectionZoned(aStart: string, aEnd: string, bStart: string, bEnd: string): {
+    start: string;
+    end: string;
+} | null;

package/dist/zoned/interval/intervalIntersectionZoned.js

@@ -0,0 +1,77 @@
+import { Temporal } from "@js-temporal/polyfill";
+import { calendarOfAllZonedValues, formatZonedInCalendar, parseCalendarZonedValue, } from "../../internal/index.js";
+import { isValidCalendarZonedDateTime } from "../validate/index.js";
+/**
+ * Return the overlapping span of two zoned intervals, or null when they do not overlap.
+ *
+ * - Uses `Temporal.ZonedDateTime.compare` for comparison (same instant semantics).
+ * - Adjacent intervals (e.g. `aEnd === bStart`) share one instant and DO overlap.
+ * - Returns `null` if either interval is invalid (`start > end`).
+ * - Returns `null` on invalid input (wrong type, malformed strings, leap seconds).
+ * - Accepts GMT calendar-annotated zoned strings (as produced by `convertZonedToCalendar`) as
+ *   well as bare ISO ones — E7 (issue #152) — but **rejects a mismatched pair**: every endpoint
+ *   must name the same calendar system (E7's D4-zoned). Unlike the ordering functions, this one
+ *   returns a *value* the caller reads back as a datetime, and there is no principled way to pick
+ *   one endpoint's calendar as the answer's. Rejection also keeps a uniform policy across all
+ *   eight value-returning zoned set operations, four of which return arrays — a per-element
+ *   "winner's tag" would produce a result set whose members disagree about which calendar they
+ *   are in. (`intervalUnionZoned`'s existing "winning endpoint's *time zone* wins" is not
+ *   precedent: the zone is a property of the surviving point, the calendar is a property of the
+ *   answer.) A mismatch returns the sentinel.
+ * - Output boundaries are re-derived in the resolved calendar via `formatZonedInCalendar`, never
+ *   copied from an input string (E7's D7-zoned).
+ * - Still rejects Temporal's own `[timeZone][u-ca=...]` RFC 9557 ordering — see
+ *   `regex/calendar-zoned-date-time.ts`.
+ *
+ * @param aStart ISO 8601 zoned datetime string for the first interval start
+ * @param aEnd ISO 8601 zoned datetime string for the first interval end
+ * @param bStart ISO 8601 zoned datetime string for the second interval start
+ * @param bEnd ISO 8601 zoned datetime string for the second interval end
+ * @returns `{ start, end }` with the overlapping span, or null on invalid input / no overlap
+ *
+ * @example intervalIntersectionZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-06-30T23:59:59+00:00[UTC]", "2024-04-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // { start: "2024-04-01T00:00:00+00:00[UTC]", end: "2024-06-30T23:59:59+00:00[UTC]" }
+ * @example intervalIntersectionZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-06-30T23:59:59+00:00[UTC]", "2024-07-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // null
+ * @example intervalIntersectionZoned("invalid", "2024-06-30T23:59:59+00:00[UTC]", "2024-04-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // null
+ */
+export function intervalIntersectionZoned(aStart, aEnd, bStart, bEnd) {
+    // One gate for all four endpoints: `isValidCalendarZonedDateTime` covers non-strings, empty
+    // strings, leap seconds (which Temporal would otherwise silently clamp to :59), unknown zones
+    // and Temporal's forbidden segment ordering, while accepting GMT's calendar-annotated grammar.
+    if (!isValidCalendarZonedDateTime(aStart) ||
+        !isValidCalendarZonedDateTime(aEnd) ||
+        !isValidCalendarZonedDateTime(bStart) ||
+        !isValidCalendarZonedDateTime(bEnd)) {
+        return null;
+    }
+    // D4-zoned reject gate: all four endpoints must agree on a calendar, or there is no calendar to
+    // express the returned value in.
+    const calendar = calendarOfAllZonedValues([aStart, aEnd, bStart, bEnd]);
+    if (!calendar) {
+        return null;
+    }
+    try {
+        const aZdt = parseCalendarZonedValue(aStart);
+        const aZde = parseCalendarZonedValue(aEnd);
+        const bZdt = parseCalendarZonedValue(bStart);
+        const bZde = parseCalendarZonedValue(bEnd);
+        if (Temporal.ZonedDateTime.compare(aZdt, aZde) > 0) {
+            return null;
+        }
+        if (Temporal.ZonedDateTime.compare(bZdt, bZde) > 0) {
+            return null;
+        }
+        if (Temporal.ZonedDateTime.compare(aZde, bZdt) < 0 ||
+            Temporal.ZonedDateTime.compare(bZde, aZdt) < 0) {
+            return null;
+        }
+        const start = Temporal.ZonedDateTime.compare(aZdt, bZdt) >= 0 ? aZdt : bZdt;
+        const end = Temporal.ZonedDateTime.compare(aZde, bZde) <= 0 ? aZde : bZde;
+        return {
+            start: formatZonedInCalendar(start, calendar),
+            end: formatZonedInCalendar(end, calendar),
+        };
+    }
+    catch {
+        return null;
+    }
+}

package/dist/zoned/interval/intervalLengthZoned.d.ts

@@ -0,0 +1,31 @@
+/**
+ * Return the exact length of a zoned interval in `unit`, as a real (possibly fractional) number.
+ *
+ * - Distinct from `intervalCountZoned`, which counts local calendar `unit` boundaries *crossed*
+ *   rather than measuring exact duration — a local day that springs forward touches 1 day
+ *   boundary via `intervalCountZoned` but is exactly `23/24 ≈ 0.958` days via
+ *   `intervalLengthZoned`.
+ * - Uses `Temporal.Duration.prototype.total` with `relativeTo` set to `start`, so the result is
+ *   DST-aware: dividing a spring-forward day's length in hours returns `23`, not `24`.
+ * - Returns `0` for a zero-length interval (`start === end`).
+ * - Accepts GMT calendar-annotated zoned strings (as produced by `convertZonedToCalendar`) as
+ *   well as bare ISO ones — E7 (issue #152). When BOTH endpoints carry the same calendar tag the
+ *   measurement is made in that calendar; when the tags mismatch, or either endpoint is bare ISO,
+ *   it falls back to Gregorian/ISO rather than returning the sentinel (E7's D5-zoned). The
+ *   fallback is mandatory, not a convenience: `ZonedDateTime.prototype.until` throws across
+ *   mismatched calendars for EVERY `largestUnit` — verified, including `"hour"` and
+ *   `"nanosecond"`.
+ * - Returns `null` on invalid input (unparseable start/end, `start > end`, unsupported unit,
+ *   leap-second strings).
+ *
+ * @param start ISO 8601 zoned datetime string for the interval start
+ * @param end ISO 8601 zoned datetime string for the interval end
+ * @param unit unit string — any `DateTimeUnit`
+ * @returns exact length of the interval expressed in `unit`, or null on invalid input
+ *
+ * @example intervalLengthZoned("2024-03-10T00:00:00-05:00[America/New_York]", "2024-03-11T00:00:00-04:00[America/New_York]", "hour") // 23 (spring forward)
+ * @example intervalLengthZoned("2024-03-10T00:00:00-05:00[America/New_York]", "2024-03-11T00:00:00-04:00[America/New_York]", "day") // 1
+ * @example intervalLengthZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-01-01T00:00:00+00:00[UTC]", "day") // 0
+ * @example intervalLengthZoned("invalid", "2024-01-02T00:00:00+00:00[UTC]", "day") // null
+ */
+export declare function intervalLengthZoned(start: string, end: string, unit: string): number | null;

package/dist/zoned/interval/intervalLengthZoned.js

@@ -0,0 +1,61 @@
+import { parseCalendarZonedPairForArithmetic, resolveDateTimeUnit, } from "../../internal/index.js";
+import { isValidDateTimeUnit } from "../../plain/validate/index.js";
+import { isValidCalendarZonedInterval } from "./validate/index.js";
+/**
+ * Return the exact length of a zoned interval in `unit`, as a real (possibly fractional) number.
+ *
+ * - Distinct from `intervalCountZoned`, which counts local calendar `unit` boundaries *crossed*
+ *   rather than measuring exact duration — a local day that springs forward touches 1 day
+ *   boundary via `intervalCountZoned` but is exactly `23/24 ≈ 0.958` days via
+ *   `intervalLengthZoned`.
+ * - Uses `Temporal.Duration.prototype.total` with `relativeTo` set to `start`, so the result is
+ *   DST-aware: dividing a spring-forward day's length in hours returns `23`, not `24`.
+ * - Returns `0` for a zero-length interval (`start === end`).
+ * - Accepts GMT calendar-annotated zoned strings (as produced by `convertZonedToCalendar`) as
+ *   well as bare ISO ones — E7 (issue #152). When BOTH endpoints carry the same calendar tag the
+ *   measurement is made in that calendar; when the tags mismatch, or either endpoint is bare ISO,
+ *   it falls back to Gregorian/ISO rather than returning the sentinel (E7's D5-zoned). The
+ *   fallback is mandatory, not a convenience: `ZonedDateTime.prototype.until` throws across
+ *   mismatched calendars for EVERY `largestUnit` — verified, including `"hour"` and
+ *   `"nanosecond"`.
+ * - Returns `null` on invalid input (unparseable start/end, `start > end`, unsupported unit,
+ *   leap-second strings).
+ *
+ * @param start ISO 8601 zoned datetime string for the interval start
+ * @param end ISO 8601 zoned datetime string for the interval end
+ * @param unit unit string — any `DateTimeUnit`
+ * @returns exact length of the interval expressed in `unit`, or null on invalid input
+ *
+ * @example intervalLengthZoned("2024-03-10T00:00:00-05:00[America/New_York]", "2024-03-11T00:00:00-04:00[America/New_York]", "hour") // 23 (spring forward)
+ * @example intervalLengthZoned("2024-03-10T00:00:00-05:00[America/New_York]", "2024-03-11T00:00:00-04:00[America/New_York]", "day") // 1
+ * @example intervalLengthZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-01-01T00:00:00+00:00[UTC]", "day") // 0
+ * @example intervalLengthZoned("invalid", "2024-01-02T00:00:00+00:00[UTC]", "day") // null
+ */
+export function intervalLengthZoned(start, end, unit) {
+    if (typeof unit !== "string") {
+        return null;
+    }
+    const resolvedUnit = resolveDateTimeUnit(unit);
+    if (!isValidDateTimeUnit(resolvedUnit)) {
+        return null;
+    }
+    if (!isValidCalendarZonedInterval(start, end)) {
+        return null;
+    }
+    try {
+        const { a: startVal, b: endVal } = parseCalendarZonedPairForArithmetic(start, end);
+        const duration = startVal.until(endVal, { largestUnit: resolvedUnit });
+        // total() with relativeTo gives the exact, DST-aware elapsed length, unlike
+        // intervalCountZoned's boundary-crossing count — a spring-forward day touches 1 day
+        // boundary via intervalCountZoned but is exactly 23/24 days (or 23 hours) here.
+        //
+        // `relativeTo` MUST be the pair policy's normalized `startVal`, never the raw parse of
+        // `start`. Anchoring to a still-calendar-tagged operand while the duration was measured in
+        // ISO does not throw — it returns a plausible-looking WRONG number (verified: 12.586…, sitting
+        // between the correct ISO 12.5666… and the correct Hebrew 13), which no sanity check catches.
+        return duration.total({ unit: resolvedUnit, relativeTo: startVal });
+    }
+    catch {
+        return null;
+    }
+}

package/dist/zoned/interval/intervalOverlappingDaysZoned.d.ts

@@ -0,0 +1,42 @@
+/**
+ * Return how many distinct calendar dates two zoned intervals share, counted in the
+ * first interval's zone.
+ *
+ * - Counts the number of local dates touched by the closed intersection
+ *   `[max(aStart, bStart), min(aEnd, bEnd)]` — inclusive of both endpoints.
+ * - `aEnd`, `bStart`, and `bEnd` are re-expressed in `aStart`'s time zone before comparing —
+ *   Temporal refuses to compute day-granularity differences directly across two zones, since
+ *   day length varies with DST/offset changes. As a result this function is NOT commutative:
+ *   swapping the two intervals can change the answer when their zones differ.
+ * - Zones whose calendar skips a date entirely (e.g. `Pacific/Apia`'s 2011 dateline change)
+ *   still count the skipped date — this matches `intervalCountZoned`'s calendar-arithmetic
+ *   rule, so the two functions never disagree about what a day is.
+ * - Adjacent intervals (e.g. `aEnd === bStart`) share one date and count as `1`.
+ * - Returns `0` when the intervals do not overlap at all (a well-defined answer, not
+ *   invalid input).
+ * - Returns `null` if either interval is invalid (`start > end`).
+ * - Returns `null` on invalid input (wrong type, malformed strings, leap seconds).
+ * - **Accepts mixed calendar systems** (E7's D4-zoned, issue #152): both bare ISO zoned strings
+ *   and GMT calendar-annotated ones (`"5784-06-15T14:30:00-05:00[u-ca=hebrew][America/New_York]"`),
+ *   and the two endpoints need not agree on a calendar. Ordering is calendar-independent —
+ *   verified that `Temporal.Instant` carries no calendar field at all and that
+ *   `Instant.compare`/`ZonedDateTime.compare` both return `0` for the same instant expressed in
+ *   hebrew, islamic-civil, japanese and iso8601.
+ * - Still rejects Temporal's own `[timeZone][u-ca=...]` RFC 9557 ordering, which reads GMT's
+ *   calendar-native digits as ISO digits — see `regex/calendar-zoned-date-time.ts`.
+ * - Diverges from date-fns's `getOverlappingDaysInIntervals`, which rounds up elapsed
+ *   24-hour periods instead of counting calendar dates. To reproduce date-fns's number,
+ *   compose `intervalIntersectionZoned` with `intervalCountZoned`:
+ *   `const span = intervalIntersectionZoned(aStart, aEnd, bStart, bEnd); span ? intervalCountZoned(span.start, span.end, "day") : 0;`
+ *
+ * @param aStart ISO 8601 zoned datetime string for the first interval start
+ * @param aEnd ISO 8601 zoned datetime string for the first interval end
+ * @param bStart ISO 8601 zoned datetime string for the second interval start
+ * @param bEnd ISO 8601 zoned datetime string for the second interval end
+ * @returns number of shared calendar dates (counted in aStart's zone), `0` when disjoint, or null on invalid input
+ *
+ * @example intervalOverlappingDaysZoned("2024-03-09T12:00:00-05:00[America/New_York]", "2024-03-11T12:00:00-04:00[America/New_York]", "2024-03-09T12:00:00-05:00[America/New_York]", "2024-03-11T12:00:00-04:00[America/New_York]") // 3 (spring-forward, 47 real hours)
+ * @example intervalOverlappingDaysZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-01-02T00:00:00+00:00[UTC]", "2024-01-03T00:00:00+00:00[UTC]", "2024-01-04T00:00:00+00:00[UTC]") // 0 (disjoint)
+ * @example intervalOverlappingDaysZoned("invalid", "2024-06-30T23:59:59+00:00[UTC]", "2024-04-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // null
+ */
+export declare function intervalOverlappingDaysZoned(aStart: string, aEnd: string, bStart: string, bEnd: string): number | null;

package/dist/zoned/interval/intervalOverlappingDaysZoned.js

@@ -0,0 +1,89 @@
+import { Temporal } from "@js-temporal/polyfill";
+import { parseCalendarZonedValue } from "../../internal/index.js";
+import { isValidCalendarZonedDateTime } from "../validate/index.js";
+/**
+ * Return how many distinct calendar dates two zoned intervals share, counted in the
+ * first interval's zone.
+ *
+ * - Counts the number of local dates touched by the closed intersection
+ *   `[max(aStart, bStart), min(aEnd, bEnd)]` — inclusive of both endpoints.
+ * - `aEnd`, `bStart`, and `bEnd` are re-expressed in `aStart`'s time zone before comparing —
+ *   Temporal refuses to compute day-granularity differences directly across two zones, since
+ *   day length varies with DST/offset changes. As a result this function is NOT commutative:
+ *   swapping the two intervals can change the answer when their zones differ.
+ * - Zones whose calendar skips a date entirely (e.g. `Pacific/Apia`'s 2011 dateline change)
+ *   still count the skipped date — this matches `intervalCountZoned`'s calendar-arithmetic
+ *   rule, so the two functions never disagree about what a day is.
+ * - Adjacent intervals (e.g. `aEnd === bStart`) share one date and count as `1`.
+ * - Returns `0` when the intervals do not overlap at all (a well-defined answer, not
+ *   invalid input).
+ * - Returns `null` if either interval is invalid (`start > end`).
+ * - Returns `null` on invalid input (wrong type, malformed strings, leap seconds).
+ * - **Accepts mixed calendar systems** (E7's D4-zoned, issue #152): both bare ISO zoned strings
+ *   and GMT calendar-annotated ones (`"5784-06-15T14:30:00-05:00[u-ca=hebrew][America/New_York]"`),
+ *   and the two endpoints need not agree on a calendar. Ordering is calendar-independent —
+ *   verified that `Temporal.Instant` carries no calendar field at all and that
+ *   `Instant.compare`/`ZonedDateTime.compare` both return `0` for the same instant expressed in
+ *   hebrew, islamic-civil, japanese and iso8601.
+ * - Still rejects Temporal's own `[timeZone][u-ca=...]` RFC 9557 ordering, which reads GMT's
+ *   calendar-native digits as ISO digits — see `regex/calendar-zoned-date-time.ts`.
+ * - Diverges from date-fns's `getOverlappingDaysInIntervals`, which rounds up elapsed
+ *   24-hour periods instead of counting calendar dates. To reproduce date-fns's number,
+ *   compose `intervalIntersectionZoned` with `intervalCountZoned`:
+ *   `const span = intervalIntersectionZoned(aStart, aEnd, bStart, bEnd); span ? intervalCountZoned(span.start, span.end, "day") : 0;`
+ *
+ * @param aStart ISO 8601 zoned datetime string for the first interval start
+ * @param aEnd ISO 8601 zoned datetime string for the first interval end
+ * @param bStart ISO 8601 zoned datetime string for the second interval start
+ * @param bEnd ISO 8601 zoned datetime string for the second interval end
+ * @returns number of shared calendar dates (counted in aStart's zone), `0` when disjoint, or null on invalid input
+ *
+ * @example intervalOverlappingDaysZoned("2024-03-09T12:00:00-05:00[America/New_York]", "2024-03-11T12:00:00-04:00[America/New_York]", "2024-03-09T12:00:00-05:00[America/New_York]", "2024-03-11T12:00:00-04:00[America/New_York]") // 3 (spring-forward, 47 real hours)
+ * @example intervalOverlappingDaysZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-01-02T00:00:00+00:00[UTC]", "2024-01-03T00:00:00+00:00[UTC]", "2024-01-04T00:00:00+00:00[UTC]") // 0 (disjoint)
+ * @example intervalOverlappingDaysZoned("invalid", "2024-06-30T23:59:59+00:00[UTC]", "2024-04-01T00:00:00+00:00[UTC]", "2024-12-31T23:59:59+00:00[UTC]") // null
+ */
+export function intervalOverlappingDaysZoned(aStart, aEnd, bStart, bEnd) {
+    // One gate for all four endpoints: `isValidCalendarZonedDateTime` already covers non-strings,
+    // empty strings, leap seconds (which Temporal would otherwise silently clamp to :59), unknown
+    // zones and Temporal's forbidden segment ordering — and, unlike `isValidZonedDateTime`, accepts
+    // GMT's calendar-annotated grammar.
+    if (!isValidCalendarZonedDateTime(aStart) ||
+        !isValidCalendarZonedDateTime(aEnd) ||
+        !isValidCalendarZonedDateTime(bStart) ||
+        !isValidCalendarZonedDateTime(bEnd)) {
+        return null;
+    }
+    try {
+        const aS = parseCalendarZonedValue(aStart);
+        // Boundaries are counted in the start's zone, so the others are re-expressed there —
+        // Temporal refuses calendar-unit differences across two zones outright.
+        const aE = parseCalendarZonedValue(aEnd).withTimeZone(aS.timeZoneId);
+        const bS = parseCalendarZonedValue(bStart).withTimeZone(aS.timeZoneId);
+        const bE = parseCalendarZonedValue(bEnd).withTimeZone(aS.timeZoneId);
+        if (Temporal.ZonedDateTime.compare(aS, aE) > 0) {
+            return null;
+        }
+        if (Temporal.ZonedDateTime.compare(bS, bE) > 0) {
+            return null;
+        }
+        if (Temporal.ZonedDateTime.compare(aE, bS) < 0 ||
+            Temporal.ZonedDateTime.compare(bE, aS) < 0) {
+            return 0;
+        }
+        const start = Temporal.ZonedDateTime.compare(aS, bS) >= 0 ? aS : bS;
+        const end = Temporal.ZonedDateTime.compare(aE, bE) <= 0 ? aE : bE;
+        // Both operands are normalized to iso8601 immediately before `.until()`. `.compare` above is
+        // calendar-independent, but `PlainDate.prototype.until` is NOT — it throws
+        // `RangeError: cannot compute difference between dates of hebrew and iso8601 calendars`
+        // whenever the two endpoints came from different calendars, which this function explicitly
+        // accepts (E7's D4-zoned). Counting distinct calendar DATES is a Gregorian/ISO question
+        // regardless of how either endpoint was tagged, so normalizing is the right answer, not just
+        // the safe one. Exactly the same hazard `intervalOverlappingDaysDate` hit in E5 (finding 2).
+        const startDate = start.toPlainDate().withCalendar("iso8601");
+        const endDate = end.toPlainDate().withCalendar("iso8601");
+        return startDate.until(endDate, { largestUnit: "day" }).days + 1;
+    }
+    catch {
+        return null;
+    }
+}

package/dist/zoned/interval/intervalSplitAtZoned.d.ts

@@ -0,0 +1,36 @@
+/**
+ * Split a zoned interval at arbitrary `points`, producing consecutive sub-intervals.
+ *
+ * - `points` need not be sorted — they are sorted internally (by instant) before splitting.
+ * - Comparison and boundary placement use the instant each point represents, so points may
+ *   carry a different time zone than `start`/`end`.
+ * - Points outside `[start, end]` are dropped; they cannot introduce a boundary that isn't
+ *   inside the interval.
+ * - Points on the same instant as `start` or `end` are dropped too — they would only produce a
+ *   zero-length sub-interval at the edge.
+ * - Duplicate points (same instant) collapse to a single boundary.
+ * - Returns `[{ start, end }]` (the whole interval, unsplit) when no valid in-range point remains.
+ * - Returns `[]` when `points` is not an array, when any element is not a valid ISO
+ *   ZonedDateTime string, or on invalid input (unparseable start/end, `start > end`,
+ *   leap-second strings).
+ * - Accepts GMT calendar-annotated zoned strings (as produced by `convertZonedToCalendar`) as
+ *   well as bare ISO ones — E7 (issue #152) — but **rejects a mismatched set**: `start`, `end`
+ *   and every element of `points` must name the same calendar system (E7's D4-zoned), since the
+ *   returned sub-intervals are values the caller reads back as datetimes and an array of
+ *   differently-tagged records would be unreadable as a set. A mismatch returns `[]`.
+ * - Output boundaries are re-derived in the resolved calendar via `formatZonedInCalendar`, never
+ *   copied from an input string (E7's D7-zoned).
+ *
+ * @param start ISO 8601 zoned datetime string for the interval start
+ * @param end ISO 8601 zoned datetime string for the interval end
+ * @param points array of ISO 8601 zoned datetime strings to split at
+ * @returns array of `{ start, end }` records, or `[]` on invalid input
+ *
+ * @example intervalSplitAtZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-01-10T00:00:00+00:00[UTC]", ["2024-01-05T00:00:00+00:00[UTC]"]) // [{ start: "2024-01-01T00:00:00+00:00[UTC]", end: "2024-01-05T00:00:00+00:00[UTC]" }, { start: "2024-01-05T00:00:00+00:00[UTC]", end: "2024-01-10T00:00:00+00:00[UTC]" }]
+ * @example intervalSplitAtZoned("2024-01-01T00:00:00+00:00[UTC]", "2024-01-10T00:00:00+00:00[UTC]", []) // [{ start: "2024-01-01T00:00:00+00:00[UTC]", end: "2024-01-10T00:00:00+00:00[UTC]" }]
+ * @example intervalSplitAtZoned("invalid", "2024-01-10T00:00:00+00:00[UTC]", ["2024-01-05T00:00:00+00:00[UTC]"]) // []
+ */
+export declare function intervalSplitAtZoned(start: string, end: string, points: string[]): Array<{
+    start: string;
+    end: string;
+}>;