@@ -29,6 +29,29 @@ const zoned = eventsInTimeZone(events, "America/New_York");
2929 instant. Keep your source events around for editing and saving.
3030</Warning >
3131
32+ ## Anchor dates are local
33+
34+ The controlled ` date ` prop, like every ` Date ` the calendar reads, is
35+ interpreted in the device's local time zone: all date math runs through
36+ date-fns (` startOfWeek ` , ` startOfMonth ` , ...) on the local clock. Construct
37+ anchors as local dates, not UTC instants:
38+
39+ ``` ts
40+ new Date (2026 , 7 , 24 ); // local Aug 24, anchors the week you expect everywhere
41+ new Date (" 2026-08-24T00:00:00Z" ); // UTC instant, still Aug 23 west of UTC
42+ ```
43+
44+ On a device west of UTC, that UTC-midnight instant is still the evening of
45+ Aug 23 locally, so a ` week ` view with ` weekStartsOn: 1 ` builds the week of
46+ Monday Aug 17, a full week before the one intended (Aug 24 is itself a
47+ Monday). The same shift moves a ` month ` anchor built from
48+ ` new Date("2026-08-01T00:00:00Z") ` into July.
49+
50+ ` timeZone ` doesn't change this: it shifts how events display, never how the
51+ ` date ` prop is read. The dates the calendar hands back (` onChangeDate ` ,
52+ ` onChangeDateRange ` , ` onPressDay ` , ...) are local dates too, so feeding them
53+ straight back into ` date ` is always safe.
54+
3255## The now indicator
3356
3457The current-time line follows the same zone as your events: set ` timeZone ` on
0 commit comments