Repository navigation
[scheduler-premium] Key recurring exDates on their data-timezone day - #23467
Merged
rita-codes merged 12 commits intoSep 1, 2026
Merged
Conversation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CC6LfHbZXD549R8qtmQojJ
Deploy previewBundle size
Check out the code infra dashboard for more information about this PR. |
rita-codes
added
type: bug
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CC6LfHbZXD549R8qtmQojJ
…ey' into scheduler-exdate-data-timezone-key
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CC6LfHbZXD549R8qtmQojJ
…spatch Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CC6LfHbZXD549R8qtmQojJ
…unction preconditions Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CC6LfHbZXD549R8qtmQojJ
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CC6LfHbZXD549R8qtmQojJ
rita-codes
changed the title
noraleonte
approved these changes
Sep 1, 2026
noraleonte
left a comment
noraleonte
left a comment
Contributor
There was a problem hiding this comment.
LGTM 👌💙
Claude liked your PR btw 😆
Per review: the dispatcher normalized occurrenceStart but not changes.start/end, so a direct caller passing both in the same zone would compare mixed labels in applyRecurringUpdateAll. Drop the dispatcher normalization instead and document the expected labels. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MidtChf5bPyveMGRfZdiMy
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MidtChf5bPyveMGRfZdiMy
rita-codes
added a commit
to rita-codes/mui-x
that referenced
this pull request
Sep 1, 2026
`toOccurrence` now resolves the occurrence start labeled in the data timezone (mui#23467), and a labeled date stringifies with an offset suffix that `resolveEventDate` re-reads as wall time — shifting cross-timezone occurrence fixtures by the UTC offset. Serialize the round-tripped model as UTC instants. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CC6LfHbZXD549R8qtmQojJ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deleting "only this event" of a recurring series could silently not stick: the occurrence re-appeared on the next render. It happened for events using instant strings (
...Z) with an explicittimezone, whenever the machine's zone differed from the event's.Why: occurrences are matched to their exDates by day, and "what day is this instant?" depends on the timezone you ask in.
resolveEventDatereturned...Zdates labeled in the machine's zone, while occurrences are keyed by their day in the event'stimezone— same instant, different day, so the exclusion never matched. The timezone docs already promise that recurrence math runs in the event'stimezone.Fix: label the parsed date in the event's timezone inside
resolveEventDate— the single string→date conversion point (#21286) — so every consumer is correct at once. This also fixes two more bugs of the same class found during review: an object-APIrrule.untilending the series one day early, and the displayBYDAYprojecting the wrong weekday. On top of that:updateRecurringEvent/deleteRecurringEventnormalizeoccurrenceStartinto the data timezone once at the dispatch, covering all five scope paths (defense for direct callers; the store already did this on its side).The instant never changes (
setTimezonekeeps the timestamp, serialization is untouched) — only which calendar the date answers day/weekday questions with.Tests (all red/green): labeling pins in
processEvent, exDate exclusion at a fixed offset and across the Nov 2025 DST fall-back, the UNTIL last day, the BYDAY projection, mislabeled-input pins on both dispatchers, and a store-level round trip (delete → serialize → reprocess → still excluded).Known pre-existing follow-up (untouched here): the RRULE string branch parses
UNTIL=...Zas wall time, now asymmetric with the object branch.Found while reviewing #23462; no file overlap.