Assertion failure in ZonedDateTime.prototype.round for backward UTC shift bridging midnight

[ptomato]

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

Reproducer:

const z = Temporal.ZonedDateTime.from("2010-03-04T23:10:00+08:00[Antarctica/Casey]");
z.round({ smallestUnit: 'day' });

What's going on here is that there was a backward UTC shift that crossed midnight. 23:10+08:00 is the repeated 23:10 wall-clock time, so it's in a piece of 2010-03-04 that occurs after a piece of 2010-03-05. In ZonedDateTime.prototype.round, we call GetStartOfDay to find the beginning and the end of the day to snap to. For the latter, GetStartOfDay disambiguates to the earlier midnight (at the end of the first piece of 2010-03-04). The assertion fails because we were not expecting the ZonedDateTime to be after the end of the day that it's supposed to round to.

Note that the relatively much more common phenomenon of a UTC shift that starts or ends at midnight, such as Brazil pre-2018, is not affected.

Also note that we use GetStartOfDay similarly to find the start of the next day in ZonedDateTime.prototype.hoursInDay. That does not fail any assertion; we already discussed it in #2938, but forgot to consider how it would affect ZonedDateTime.prototype.round. Applied to this case, z.hoursInDay could plausibly return either 24 (length of the first piece of 2010-03-04) or 27 (length from the first moment of 2010-03-04 until the last moment, including a discontiguous piece of 2010-03-05). We chose the former, and documented it as such. Whatever resolution we pick here should be consistent with hoursInDay (or else we should consider changing the hoursInDay behaviour as well.)

[ptomato]

Trying to figure out what the correct result should be, I drew this crappy diagram:

I'd say to be consistent with hoursInDay, we'd want the result of round({ smallestUnit: 'day' }) to be the start of the first 03-05 (short blue line).

If we decide that 27 is a better result for hoursInDay, we'd want the result of round({ smallestUnit: 'day' }) to be the end of the second 03-04 (short red line).

[ptomato]

We discussed this in the Temporal meeting of 2026-05-07. We believe these are the invariants here:

• The startOfDay() method should always return the first midnight, if midnight is repeated due to a UTC transition.
• startOfDay() plus a duration corresponding to the hoursInDay property should always result in the following day's startOfDay().
• zdt.round({ smallestUnit: 'day' }) should snap the ZonedDateTime to either the startOfDay() of the current day, or the startOfDay() of the next day.

So the result of hoursInDay for 2010-03-04 being 24 is correct according to these invariants. The result of the rounding should be 2010-03-05T00:00+11:00 (the start of the first 03-05, the short blue line in the diagram). This result may be odd-looking if considered in isolation (we jump from the second red line to the first red line, that's weird) but we think it makes sense as the best choice that is consistent with the above invariants.

We get this desired result if we just delete the assertion, and not enforce thisNs < endNs in ZonedDateTime.round step 19.f. So the assertion is just invalid, it can be an editorial change.

Here's what I'll do:

• Verify that this fix is indeed correct
• Add test262 cases
• Add an exhaustive test for the above invariants and see if any other cases fail
• Remove the assertion in the reference polyfill
• Remove the assertion in the stage 4 ecma262 PR with a commit marked "(fixup)"

[ptomato]

I wrote test262 tests in tc39/test262#5047 but marked them as a draft because when I went back to the Firefox bug report I realized I had missed an additional wrinkle that they had mentioned.

> z.round({ smallestUnit: 'day', roundingMode: 'ceil' })
  // Temporal.ZonedDateTime <2010-03-05T21:00:00+08:00[Antarctica/Casey]>

Adding roundingMode: 'ceil' gives a garbage result with our proposed fix. This is because startNs to thisNs spans about 110% of the day length, which rounds up to 200% with roundingMode ceil. That incorrectly adds an extra 24 hours, and because of the UTC shift the result isn't even on a day boundary.

So our proposed fix from today is unfortunately insufficient.

My first idea is to change 19.f. to "Set thisNs to min(thisNs, endNs - 1)." This would cap the startNs to thisNs span at <100% of the day length. I'll still need to validate this, and it might be a normative change after all.

[justingrant]

Is this single time zone transition the only one that would be affected, or are there others?

My first idea is to change 19.f. to "Set thisNs to min(thisNs, endNs - 1)."

This sounds like a reasonable solution to this rare and weird case.