Assertion failure and shady results in DifferenceZonedDateTime across backward UTC shift

[ptomato]

Discovered thanks to Firefox fuzzing: https://bugzilla.mozilla.org/show_bug.cgi?id=2028872

Reproducer:

const zdt1 = Temporal.ZonedDateTime.from('1867-10-18T12:44:35.000000001-11:47[America/Adak]');
const zdt2 = Temporal.ZonedDateTime.from('1867-10-19T00:00:00+12:13[America/Adak]');
const realDuration = zdt1.since(zdt2);

zdt1.since(zdt2, { largestUnit: 'days' });
zdt2.until(zdt1, { largestUnit: 'days' });
realDuration.round({ largestUnit: 'days', relativeTo: zdt2 });
realDuration.total({ unit: 'days', relativeTo: zdt2 });

The four method calls (since, until, round, total) all hit the assertion in step 3 of CombineDateAndTimeDuration ("Assert: If dateSign ≠ 0 and timeSign ≠ 0, dateSign = timeSign.") via step 15 of DifferenceZonedDateTime ("Return CombineDateAndTimeDuration(dateDifference, timeDuration)"). The cause is pretty simple. For the input data above, zdt1 is chronologically later than zdt2 but earlier on the wall-clock, because of the backwards time zone shift. The day correction loop in DifferenceZonedDateTime handles that fine if the two times occur within the same calendar day, but here they don't and that's exactly the case that fails the assertion.

I'm not 100% sure what the results of the above calls should be, but my first guess would be that since, until, and round should all return a duration of equal length to realDuration. We should figure this out first, and then add test262 tests and adjust the assertion accordingly, since it is invalid.

In addition while investigating this, I also found shady results when rounding relative to the later ZonedDateTime (zdt1 instead of zdt2):

// Note, realDuration is PT12H44M35.000000001S
realDuration.round({ largestUnit: 'days', relativeTo: zdt1 });
  // PT36H44M35.000000001S
realDuration.total({ unit: 'days', relativeTo: zdt1 });
  // 0.5309606481481597

At first glance, the total result looks correct (it's the float approximation of (12 + 44/60 + 35/3600 + 1/3600e9) / 24), but the round result looks completely wrong and should probably be equal to realDuration. I still need to double-check these results and find where the bug (if any) is.

[ptomato]

cc @arshaw here as well, you might have some insight into this

[ptomato]

I found another instance of this assertion failure while debugging #3312.

relativeTo = Temporal.ZonedDateTime.from('2010-03-04T23:10:00+08:00[Antarctica/Casey]')
new Temporal.Duration(0, 0, 0, 0, -1).total({ unit: 'days', relativeTo })
  // also for unit years, months, weeks

(Note this is not a 24-hour shift, so removing that from the title)

[justingrant]

@ptomato Does the same fix proposed in #3315 also solve the problems in this issue?

[justingrant]

I'm not 100% sure what the results of the above calls should be, but my first guess would be that since, until, and round should all return a duration of equal length to realDuration. We should figure this out first, and then add test262 tests and adjust the assertion accordingly, since it is invalid.

I think answering "what should the result be?" could benefit by revisiting the original definition of the until/since algorithm, which IIRC was something like this:

If the receiver is equal to the argument, return PT0S

If the receiver is earlier than the argument on the absolute timeline, loop over all units from largest unit to smallest unt, largest first.

1. For each unit, start with 1 unit and try adding it to the receiver, using defaults for disambiguation and constrain.
2. Keep trying successively further-away-from-zero numbers of units until the result is later than the argument.
3. Back up one unit and use this is the unit value to set in the resulting duration

If the receiver is later than the argument on the absolute timeline, do the same except swap subtraction/addition and later/earlier.

since works like until, except once the result is complete, negate the duration.

Using this definition of the algorithm, I'd get something like this for zdt2.until(zdt1, { largestUnit: 'days' }):

• zdt2 is earlier than zdt1 on the timeline, so we'd use addition
• If you start with the receiver (1867-10-19T00:00:00+12:13[America/Adak]) and add one day (using default disambiguation & constrain behavior) you get 1867-10-20T00:00:00-11:47[America/Adak] which is beyond zdt1. So days will be zero.
• At this point subtraction only uses time durations, so it's a straightforward result in number of hours, minutes, seconds, etc.

And for zdt1.since(zdt2, { largestUnit: 'days' }):

• zdt1 is later than zdt2 on the timeline, so we'd use subtraction
• If you start with the receiver(1867-10-18T12:44:35.000000001-11:47[America/Adak]) and subtract one day you get 1867-10-17T12:44:35.000000001-11:47[America/Adak] which is beyond zdt2. So days will be zero.
• At this point subtraction only uses time durations, so it's a straightforward result in number of hours, minutes, seconds, etc.

I know the algorithm above isn't how we actually wrote the spec text, but I think we can use that high-level algorithm as our north star to know whether a change or a result is the correct one: is it consistent with the simple algoirthm above?

[ptomato]

Does the same fix proposed in #3315 also solve the problems in this issue?

Unfortunately no, in fact this issue will block the snapshot tests in that PR from landing.

[arshaw]

Please see my preliminary solution here: #3317