ZonedDateTime until / since assertion failure for same-day times across Fall DST

[phensley]

I've reported an assertion failure of the ZonedDateTime until / since methods js-temporal/temporal-polyfill#347 which also fails in Firefox 141.0 with a slightly different error.

The two ZonedDateTime are valid but their times span the Fall DST boundary:

const zone = 'America/Vancouver';

// Sunday, November 2, 2025 8:01:00 AM UTC
// 2025-11-02 01:01:00-07:00 Local
const epoch1 = 1762070460000;

// Sunday, November 2, 2025 9:00:00 AM UTC
// 2025-11-02 01:00:00-08:00 Local
const epoch2 = 1762074000000;

const date1 = Temporal.Instant.fromEpochMilliseconds(epoch2).toZonedDateTimeISO(zone);
const date2 = Temporal.Instant.fromEpochMilliseconds(epoch1).toZonedDateTimeISO(zone);

// date2.until(date1) also fails
date1.until(date2, { largestUnit: 'year', smallestUnit: 'millisecond' });

The polyfill throws:

RangeError: mixed-sign values not allowed as duration fields

 ❯ ES.RejectDuration ../../node_modules/.pnpm/@js-temporal+polyfill@0.5.1/node_modules/@js-temporal/polyfill/lib/ecmascript.ts:3250:50
 ❯ new Duration ../../node_modules/.pnpm/@js-temporal+polyfill@0.5.1/node_modules/@js-temporal/polyfill/lib/duration.ts:54:5
 ❯ TemporalDurationFromInternal ../../node_modules/.pnpm/@js-temporal+polyfill@0.5.1/node_modules/@js-temporal/polyfill/lib/ecmascript.ts:3400:10
 ❯ ES.DifferenceTemporalZonedDateTime ../../node_modules/.pnpm/@js-temporal+polyfill@0.5.1/node_modules/@js-temporal/polyfill/lib/ecmascript.ts:4383:14
 ❯ Temporal.ZonedDateTime.until ../../node_modules/.pnpm/@js-temporal+polyfill@0.5.1/node_modules/@js-temporal/polyfill/lib/zoneddatetime.ts:226:12

Firefox throws:

Uncaught RangeError: duration value "hours" has a mismatched sign: -24

Given that both the polyfill and Firefox native implementations fail this may be the correct behavior for these inputs?

A valid result for these inputs could be "-1 minute" if using wall clock time / disambiguation, or "59 minutes"if using absolute time.

If the spec is correct and callers are expected to try-catch this call, perhaps a more clarifying error could be thrown by the controlling function (DifferenceZonedDateTime).

[justingrant]

This is definitely a bug somewhere. Not sure if the bug is in the spec or in tests/implementation, but thanks for reporting it!

FYI @anba @ptomato

[anba]

This seems to be a spec-bug. https://tc39.es/proposal-temporal/#sec-temporal-differencezoneddatetime, step 14 attempts to combine a date-duration and a time-duration with different signs, which isn't allowed. (See https://tc39.es/proposal-temporal/#sec-temporal-combinedateandtimeduration, step 3.)

(Note: The test case constructs date1 from epoch2 and date2 from epoch1, so ns1 below is for date1 which is epoch2.)

From a GDB session, variable names match the names from the spec algorithm:

(gdb) p ns1
$1 = (const js::temporal::EpochNanoseconds &) @0x7fffffff9718: {<js::temporal::SecondsAndNanoseconds<js::temporal::EpochNanoseconds>> = {seconds = 1762074000, nanoseconds = 0}, <No data fields>}
(gdb) p ns2
$2 = (const js::temporal::EpochNanoseconds &) @0x7fffffff96c0: {<js::temporal::SecondsAndNanoseconds<js::temporal::EpochNanoseconds>> = {seconds = 1762070460, nanoseconds = 0}, <No data fields>}
(gdb) p startDateTime
$3 = {date = {year = 2025, month = 11, day = 2}, time = {hour = 1, minute = 0, second = 0, millisecond = 0, microsecond = 0, nanosecond = 0}}
(gdb) p endDateTime
$4 = {date = {year = 2025, month = 11, day = 2}, time = {hour = 1, minute = 1, second = 0, millisecond = 0, microsecond = 0, nanosecond = 0}}
(gdb) p sign
$5 = -1
(gdb) p maxDayCorrection
$6 = 1
(gdb) p timeDuration
$7 = {<js::temporal::SecondsAndNanoseconds<js::temporal::TimeDuration>> = {seconds = 60, nanoseconds = 0}, <No data fields>}
(gdb) p dayCorrection
$8 = 1
(gdb) p TimeDurationSign(timeDuration)
$9 = 1
(gdb) p intermediateDateTime
$10 = {date = {year = 2025, month = 11, day = 3}, time = {hour = 1, minute = 0, second = 0, millisecond = 0, microsecond = 0, nanosecond = 0}}
(gdb) p intermediateNs
$11 = {<js::temporal::SecondsAndNanoseconds<js::temporal::EpochNanoseconds>> = {seconds = 1762160400, nanoseconds = 0}, <No data fields>}
(gdb) p timeDuration
$12 = {<js::temporal::SecondsAndNanoseconds<js::temporal::TimeDuration>> = {seconds = -89940, nanoseconds = 0}, <No data fields>}
(gdb) p timeSign
$13 = -1
(gdb) p dateLargestUnit
$14 = js::temporal::TemporalUnit::Year
(gdb) p dateDifference
$15 = {years = 0, months = 0, weeks = 0, days = 1}
(gdb) n
[961473] Assertion failure: DateDurationSign(dateDifference) * TimeDurationSign(timeDuration) >= 0, at /home/andre/hg/mozilla-central/js/src/builtin/temporal/ZonedDateTime.cpp:753

[ptomato]

Unfortunately this is a regression from #2810 which was a normative change approved in February 2024.

I think we can solve this by reconciling the mixed signs before calling CombineDateAndTimeDuration. But I'd have to study this some more to figure out where exactly the logic error is. Maybe there's something we need to change in the loop instead, to guarantee there are no mixed signs when it's finished.

An alternative would be to bring back the old algorithm that we rewrote in #2810 while still fixing the bug that we intended to fix with the rewrite (e.g., 20e761a, but that would need more testing as well.)

Either way this will need test coverage.

cc @arshaw - that was the commit where we replaced the existing algorithm with the maxDayCorrection loop. I'm guessing you have this bug too.

[arshaw]

Hi @ptomato, I'll take a look this week! Happy to take the lead since I wrote most of this algorithm.

[ptomato]

Thanks. here's what I have so far that seems to fix the problem, but I haven't dug into why this happens.

--- a/polyfill/lib/ecmascript.mjs
+++ b/polyfill/lib/ecmascript.mjs
@@ -3147,7 +3147,13 @@ export function DifferenceZonedDateTime(ns1, ns2, timeZone, calendar, largestUni
 
   // Similar to what happens in DifferenceISODateTime with date parts only:
   const dateLargestUnit = LargerOfTwoTemporalUnits('day', largestUnit);
-  const dateDifference = CalendarDateUntil(calendar, isoDtStart.isoDate, intermediateDateTime.isoDate, dateLargestUnit);
+  let dateDifference = CalendarDateUntil(calendar, isoDtStart.isoDate, intermediateDateTime.isoDate, dateLargestUnit);
+  const dateSign = DateDurationSign(dateDifference);
+  const timeSign = timeDuration.sign();
+  if (dateSign !== 0 && timeSign !== 0 && dateSign !== timeSign) {
+    dateDifference = AdjustDateDurationRecord(dateDifference, dateDifference.days + timeSign);
+    timeDuration = timeDuration.add24HourDays(-timeSign);
+  }
   return CombineDateAndTimeDuration(dateDifference, timeDuration);
 }

[arshaw]

Please see this PR: #3147

The problem was happening when dayCorrection was backing up too far, beyond the start-point. This would happen when the start and end ZDTs had the same Y-M-D value and had a wallclock time with a sign that was different than the sign of the epoch-to-epoch diff.

[ptomato]

Unfortunately I managed to trigger a new assertion with this fix:

Temporal.Duration.from({ minutes: -59 }).round({
  smallestUnit: 'days',
  relativeTo: '2025-11-02T01:00:00-08:00[America/Vancouver]'
});

Previously this would hit the mixed-sign assertion failure. Now it fails the assertion in NudgeToCalendarUnit step 13 or 14. Looks like a similar root cause?

[arshaw]

I see what you mean @ptomato. I devised a fix for this and will update the PRs very soon. It led me to some other bugs involve fall-back DST gaps and NudgeToCalendarUnit that I will create tickets for