fix: exclude timed EXDATE instances crossing UTC midnight due to DST#464
fix: exclude timed EXDATE instances crossing UTC midnight due to DST#464jens-maus merged 1 commit intojens-maus:masterfrom
Conversation
When a recurring timed event has an EXDATE and the event time crosses UTC midnight due to a DST offset (e.g. 16:00 PST = 00:00Z the next day), the instance was not excluded as expected. generateDateKey() returns the UTC date portion (e.g. "2023-11-09"), but the EXDATE parser stores two keys for the occurrence: - "2023-11-08" — the local calendar date (via getDateKey/Temporal) - "2023-11-09T00:00:00.000Z" — the full ISO string Neither matched "2023-11-09", so the EXDATE check silently failed. Fix: fall back to the full ISO string lookup when the date-only key misses, matching the full-ISO key already stored by the dual-key parser. Add regression test covering a weekly 16:00 America/Los_Angeles event with an EXDATE on the first occurrence after the PDT→PST switch.
|
No actionable comments were generated in the recent review. 🎉 📝 WalkthroughWalkthroughThe pull request extends EXDATE exclusion logic to check both a generated dateKey and ISO string representation ( Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
The "1 configuration not found" CodeQL warning is a pre-existing issue unrelated to this PR — commit 54bef15 renamed the language from Coderabbit seems satisfied. In my view, this can be merged 🙂 |
|
@jens-maus Thanks for the quick merges! A new release would be nice since this blocks my efforts implementing expandRecurringEvent in MagicMirror 🙂 |
While implementing
expandRecurringEventin MagicMirror I noticed a subtle bug: recurring timed events with an EXDATE weren't always excluded correctly.The culprit is a DST edge case — when an event's local time crosses UTC midnight (e.g. 16:00 PST = 00:00 UTC the next day), the date-only key from
generateDateKey()("2023-11-09") matches neither key stored by the parser ("2023-11-08" local date, or "2023-11-09T00:00:00.000Z" full ISO string).The fix adds a fallback to the full ISO string lookup, consistent with the dual-key storage already in the parser.
Includes a regression test with a weekly 16:00 America/Los_Angeles event and an EXDATE on the first occurrence after the PDT→PST switch.
Summary by CodeRabbit
Bug Fixes
Tests