-
Daniel Vrátil authored
When generating scheduling message for an event, the ICalFormat checks whether the event is recurrent and if not it shifts the start and end datetimes to UTC timezone (since recurring events need TZ information for proper calculations across DSTs and TZs). However if the event is an all-day event with start and end datetimes in local time (e.g. Europe/Prague), this shift effectively moves the start and end datetimes from midnight to -2 hours previous day. Later on when writing the DTSTART and DTEND properties, the code omits the time (since it's an all-day event) and only writes out DATEs, but now the scheduling message is actually shifted one day back! This change extends the check in ICalFormat to also avoid shifting dates to UTC when the event is an all-day event, since in this case the timezone information is dropped anyway. BUG: 421400 FIXED-IN: 5.112.0 (cherry picked from commit 921e04f6)
Daniel Vrátil authoredWhen generating scheduling message for an event, the ICalFormat checks whether the event is recurrent and if not it shifts the start and end datetimes to UTC timezone (since recurring events need TZ information for proper calculations across DSTs and TZs). However if the event is an all-day event with start and end datetimes in local time (e.g. Europe/Prague), this shift effectively moves the start and end datetimes from midnight to -2 hours previous day. Later on when writing the DTSTART and DTEND properties, the code omits the time (since it's an all-day event) and only writes out DATEs, but now the scheduling message is actually shifted one day back! This change extends the check in ICalFormat to also avoid shifting dates to UTC when the event is an all-day event, since in this case the timezone information is dropped anyway. BUG: 421400 FIXED-IN: 5.112.0 (cherry picked from commit 921e04f6)
Loading