Ruled: 5881826705 · letter B (month grid moves by calendar days, keeps the wall-clock time) · 2026-09-29T01:25Z
Filed by the objectui domain:ui seat #1 (session_01DuWo5bdP9SdVebamn99GGk) from objectui#10866 slice 4 (PR objectui#10994): its dev's open question, and contract review 5873110729, which reproduced the defect. ⛔ Not graded here. This is a behaviour question about instants, so it needs the maintainer's ruling, not a dev's or a seat's choice.
What happens (measured)
CalendarView's MonthView.handleDrop moves an event by the milliseconds between the grab cell's local midnight and the drop cell's local midnight. Across a DST change that span is 23 or 25 hours, so:
- Every datetime moved across a DST change shifts its wall-clock time by an hour.
- A datetime at local midnight lands at 23:00 in the cell BEFORE the drop. Measured in America/Los_Angeles, identically on objectui
main and on PR objectui#10994's head: a start of 2026-11-01T07:00:00.000Z (Nov 1, 00:00 local), grabbed on Nov 2 and dropped on Nov 3, is written as 2026-11-02T07:00:00.000Z, which is Nov 1, 23:00 local.
- The calendar's own month-view quick-create writes exactly such local-midnight instants into datetime fields (pinned in slice 4's tests), so this reaches documents the calendar itself created.
Date-only values do not have this problem after PR objectui#10994: its ObjectCalendar repair moves a stored day by whole calendar days. That repair lives in the consumer because the grid cannot tell a day from an instant at local midnight.
Why it is a ruling, not a fix
objectui#10866's binding reading (release 5870108114) is "a datetime keeps its instant". Any fix here changes the instant a datetime move writes. That is exactly the kind of unruled instant change contract review 5869002399 failed on this card's slice 3.
Options
- A. Leave it (today's state). Instants keep the grid's elapsed-time arithmetic; days are already repaired. Cost: a datetime moved across a DST change keeps its elapsed duration, not its wall-clock time.
- B. Move by calendar days in the grid for every value, keeping the wall-clock time. A datetime at 10:00 stays at 10:00 on the dropped day, whatever the DST change. This is the behaviour most calendar products show, and it would also make the consumer-side day repair redundant. It is an instant behaviour change: every datetime moved across a DST change lands one hour away from where the arithmetic puts it today.
- C. Move by calendar days only for values at local midnight. It fixes the previous-cell case, but it is a heuristic: it misfires on real midnight events, and it leaves the one-hour shift for every other datetime.
Seat's recommendation: B, as a small plugin-calendar slice with zone pins under LA and Shanghai. The reason is that the user moved an event to a day, not by a number of milliseconds. The review of PR objectui#10994 agrees that B is the right eventual fix for the whole class. The seat does not decide it: it changes what an instant field stores, which is outside every ruling on objectui#10866 so far.
Dedupe words: calendar month drag DST instant previous cell, CalendarView MonthView handleDrop elapsed ms, month grid move datetime DST wall clock.
Generated by Claude Code
Ruled: 5881826705 · letter B (month grid moves by calendar days, keeps the wall-clock time) · 2026-09-29T01:25Z
Filed by the objectui
domain:uiseat #1 (session_01DuWo5bdP9SdVebamn99GGk) from objectui#10866 slice 4 (PR objectui#10994): its dev's open question, and contract review5873110729, which reproduced the defect. ⛔ Not graded here. This is a behaviour question about instants, so it needs the maintainer's ruling, not a dev's or a seat's choice.What happens (measured)
CalendarView'sMonthView.handleDropmoves an event by the milliseconds between the grab cell's local midnight and the drop cell's local midnight. Across a DST change that span is 23 or 25 hours, so:mainand on PR objectui#10994's head: a start of2026-11-01T07:00:00.000Z(Nov 1, 00:00 local), grabbed on Nov 2 and dropped on Nov 3, is written as2026-11-02T07:00:00.000Z, which is Nov 1, 23:00 local.Date-only values do not have this problem after PR objectui#10994: its
ObjectCalendarrepair moves a stored day by whole calendar days. That repair lives in the consumer because the grid cannot tell a day from an instant at local midnight.Why it is a ruling, not a fix
objectui#10866's binding reading (release
5870108114) is "adatetimekeeps its instant". Any fix here changes the instant a datetime move writes. That is exactly the kind of unruled instant change contract review5869002399failed on this card's slice 3.Options
Seat's recommendation: B, as a small
plugin-calendarslice with zone pins under LA and Shanghai. The reason is that the user moved an event to a day, not by a number of milliseconds. The review of PR objectui#10994 agrees that B is the right eventual fix for the whole class. The seat does not decide it: it changes what an instant field stores, which is outside every ruling on objectui#10866 so far.Dedupe words: calendar month drag DST instant previous cell, CalendarView MonthView handleDrop elapsed ms, month grid move datetime DST wall clock.
Generated by Claude Code