Repository navigation
fix: keep a calendar's own VTIMEZONE over the generated one - #341
Merged
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
🚀 New features to boost your workflow:
|
abe-101
force-pushed
the
fix/keep-source-vtimezone
branch
from
November 3, 2026 21:27
80a63c8 to
9385e3d
Compare
A TeamSnap feed publishes a correct RRULE VTIMEZONE, but merged output carries the generated RDATE one instead. Fails until the next commit. Assistant-model: Claude Code
Merged output lost the calendar's RRULE definition whenever X-WR-TIMEZONE was set. Outlook shows those events an hour late after DST ends. Assistant-model: Claude Code
abe-101
force-pushed
the
fix/keep-source-vtimezone
branch
from
November 3, 2026 21:28
9385e3d to
c4384a4
Compare
There was a problem hiding this comment.
🟢 Approval recommended
There are no active review issues for the change to preserve source timezone definitions.
No open issues 🎉
What changed in this PR
Preserves a source calendar’s own VTIMEZONE when normalization generates another definition with the same TZID. This addresses the reported TeamSnap timezone replacement; the Outlook behavior remains unverified.
Changes:
- Reverses timezone traversal so the source definition takes precedence over the generated one.
- Adds a TeamSnap fixture and regression test checking that recurrence rules, timezone content, and event start time are preserved.
| File | Description |
|---|---|
| tests/test_issue_1_include_timezones.py | Adds regression coverage for preserving the source timezone definition. |
| tests/calendars/teamsnap_x_wr_timezone.ics | Adds a TeamSnap fixture containing both X-WR-TIMEZONE and VTIMEZONE. |
| src/mergecal/calendar_merger.py | Reverses timezone traversal before deduplicating by TZID. |
Review effort: Balanced
Member
Author
|
@niccokunzmann Let me know if you plan to review this; otherwise I'll just merge it (I'll wait 24 hours for a response) |
This branch was successfully deployed
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.
If you merge a TeamSnap feed, the output loses its RRULE
VTIMEZONEand gets a generated RDATE one instead. Outlook shows those events an hour late after DST ends.This happens with any calendar that has both
X-WR-TIMEZONEand its ownVTIMEZONE.to_standard()puts a generatedVTIMEZONEahead of the calendar's own, andmerge()keeps the first one per TZID. Now the calendar's own wins.The new test without the fix. Each tuple is (block, has RRULE, has RDATE):
The fixture is trimmed from an anonymized copy of a real feed.
I haven't confirmed this fixes Outlook yet, only that the output keeps TeamSnap's definition.
Merging this releases 0.6.2.