Handle double midnight in ZonedDateTime.round#3315
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3315 +/- ##
=======================================
Coverage 98.39% 98.39%
=======================================
Files 22 22
Lines 10763 10796 +33
Branches 1866 1875 +9
=======================================
+ Hits 10590 10623 +33
Misses 161 161
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. |
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. |
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
f7805ae to
564458f
Compare
Recently new test262 tests were added that test the order of observable reads in the DateTimeFormat constructor more strictly. Property reads should be interleaved with the observable calls to toString/valueOf. Implement this in our polyfilled DateTimeFormat constructor so that it adheres to the spec and passes the test262 tests.
564458f to
81a6886
Compare
Tentative solution to #3312. If we like this solution, I'll make the change in the spec text.