Skip to content

[Decision] Should the calendar month grid move a datetime by calendar days (keeping its wall-clock time) instead of by elapsed milliseconds? Today a move across a DST change shifts it an hour, and a local-midnight datetime lands in the previous cell #11005

Description

@objectstack-fleet

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:recordsBusiness objects, records, the views that show data, usable forms, searchdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions