fix(calendar): prefix TZID with '/' to use globally-defined IANA timezone identifiers#60588
Draft
miaulalala wants to merge 1 commit into
Draft
fix(calendar): prefix TZID with '/' to use globally-defined IANA timezone identifiers#60588miaulalala wants to merge 1 commit into
miaulalala wants to merge 1 commit into
Conversation
miaulalala
requested review from
a team,
ChristophWurst,
SebastianKrupinski and
tcitworld
as code owners
miaulalala
requested review from
Altahrim,
ArtificialOwl,
artonge and
salmart-dev
and removed request for
a team
…zone identifiers Without a leading '/', a TZID like 'Europe/Berlin' in DTSTART/DTEND requires an accompanying VTIMEZONE component (RFC 5545 §3.2.19). CalendarEventBuilder never emits VTIMEZONE, so Sabre's iTIP broker had nothing to copy into invite emails — leaving recipients with a dangling TZID reference that clients like Grommunio misinterpret as an unknown timezone. Prepending '/' makes the TZID a globally-defined IANA identifier, which is valid without VTIMEZONE and is universally understood. UTC datetimes (Z suffix, no TZID) are unaffected. AI-Assisted-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Anna Larch <anna@nextcloud.com>
miaulalala
force-pushed
the
fix/calendar-event-builder-vtimezone
branch
from
4d254ba to
e1d05d0
Compare
susnux
added
bug
3. to review
Contributor
Author
|
/backport to stable34 |
Contributor
Author
|
/backport to stable33 |
Contributor
Author
|
/backport to stable32 |
Contributor
Author
|
Once sabre-io/vobject#757 is fixed and the updated Sabre VObject version is vendored into Nextcloud, this PR can be reverted — the |
Member
|
It would be nice if someone made sure this doesn't cause regressions in other popular clients that don't understand correctly globally-defined timezone identifiers. In any case, the spec says |
2 tasks
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
3 participants
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.
Summary
CalendarEventBuilder::toIcs()emitsDTSTART;TZID=Europe/Berlin:...but never includes aVTIMEZONEcomponentVTIMEZONEcomponents into invite emails — so without one, attendees receive an ICS with a dangling TZID referenceRFC 5545 §3.2.19 allows a leading
/on a TZID to indicate a globally-defined IANA identifier, which is valid without aVTIMEZONEblock. This PR applies that prefix toDTSTARTandDTENDbefore serialisation. UTC datetimes (Z-suffix, no TZID) are unaffected.Test plan
php vendor-bin/phpunit/vendor/phpunit/phpunit/phpunit --no-coverage -c tests/phpunit-autotest.xml tests/lib/Calendar/CalendarEventBuilderTest.php— all 8 tests passtestToIcsWithTimezoneassertsDTSTART;TZID=/Europe/Berlin:, noBEGIN:VTIMEZONE, and matches the full fixturetestToIcsWithUtcIsUnchangedasserts UTC datetimes are not alteredFixes: nextcloud/spreed#18039 (workaround on the Talk side is in nextcloud/spreed#XXXX)
🤖 Generated with Claude Code