Handle double midnight in ZonedDateTime.round#3315
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3315 +/- ##
==========================================
- Coverage 98.39% 98.38% -0.01%
==========================================
Files 22 22
Lines 10763 10769 +6
Branches 1866 1868 +2
==========================================
+ Hits 10590 10595 +5
- Misses 161 162 +1
Partials 12 12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
justingrant
left a comment
There was a problem hiding this comment.
I think this is fine? Not 100% confident but it seems reasonable to handle the one known case of this.
|
Although the snapshot tests fail. Is that expected? |
a2882c6 to
1f65a30
Compare
Well, I did forget to update the snapshot files, which I've done now. But one of them still fails because the Antarctica/Casey case also hits the assertion in #3311, so we won't get a clean run until we have a solution for that. |
|
Proposing the spec change in https://ptomato.name/talks/tc39-2026-05/#6. |
For all of our interesting ZonedDateTimes, test the startOfDay() and hoursInDay invariants. See discussion in #3312
The assertion in the previous code was a problem in cases where a backwards UTC shift spanned across midnight (i.e. from a time after midnight to a time before midnight, not starting or ending at midnight.) It would produce a span of startNs...thisNs that was longer than 100% of the day length, which failed the assertion, but would also mess up rounding modes (would expand to 200% of the day length, for example.) See: #3312
1f65a30 to
f7805ae
Compare
|
The needs-consensus PR that corresponds to this fix reached TC39 consensus in the meeting of 2026-05-19. |
|
I removed the new case from the snapshot files, since it doesn't fully pass them until we also fix #3311. I'll re-add it then. |
Tentative solution to #3312. If we like this solution, I'll make the change in the spec text.