-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(dav): Prevent out-of-office event time drifts #42142
Conversation
/backport to stable28 |
$vCalendar->add($vtimezone); | ||
|
||
/** @psalm-suppress UndefinedMethod */ | ||
$vEvent->DTSTART->setDateTime($start->setTimezone($calendarTimeZone)->setTime(0, 0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the day drift happened here because we set the time above without a timezone. if the actual time is on UTC+1 and you set to 00:00 the date moves by one day. So even if we set the time again here, it's one day too early.
setting timezone first, then the time ensures that the day does not change unexpectedly
Want to create an issue to have such a service that generates VTIMEZONE data? There's probably a lot of places it could be used. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable
@miaulalala could you please test it, too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense
Tested it, works. |
Signed-off-by: Christoph Wurst <[email protected]>
8067a49
to
9abfcad
Compare
/backport to stable28 |
accidentally merged the wrong PR, sorry. ^ recreating the backport. |
Summary
This fixes both symptoms of #42139
Users whose calendar has no
timezone
property had wrong calendar start dates when their actual timezone has an offset from UTC. This happens for CET for example. The fix is to use the new timezone service that has more sources for a timezone and therefore higher changing of finding data.The known downside of this fix is that in contrast to the calendar timezone, the timezone service only returns the timezone id, not the full VTIMEZONE object. Therefore the ooo events have DTSTART and DTEND with TZID=x but no VTIMEZONE component. This is not ideal but IMO a better solution than the current drifts.
How to test
timezone
to NULL in oc_calendarsmaster: event is created, but at UTC and it starts one day before absence if you live in UTC+1
here: event is created, has DTSTART and DTEND set to your timezone id and starts at the first day of absence.
Checklist