Bug 184628 - Recurring events created in KDE 3.5 MUST be converted to local time zone to result in the same recurrence dates
Summary: Recurring events created in KDE 3.5 MUST be converted to local time zone to r...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: korganizer
Classification: Applications
Component: recurrence (show other bugs)
Version: 4.2.0
Platform: Ubuntu Linux
: NOR grave
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-17 13:24 UTC by Reinhold Kainhofer
Modified: 2017-01-07 21:37 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Reinhold Kainhofer 2009-02-17 13:24:06 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Ubuntu Packages

Recurring events were treated in KDE 3.5 as if the DTSTART was given in local time (even though they were written out in UTC). In particular, while the DTSTART was stored in UTC, it was immediately converted to the local time zone when loading the event. The RRULE was then calculated starting from the start time in LOCAL TIME.

In KDE 4 they use the TZ given for the DTSTART, so the recurrence instances are calculated from the DTSTART as given in UTC (which might be a different date) and only afterwards converted to the view's timezone.

So the DTSTART **MUST** be converted to the local time zone on loading (can be done using a compat rule). Otherwise, all events where the start time in UTC and in the local time zone are on different dates (e.g. an event at 0:30 CET, which is stored as 23:30 UTC on the previous date) are possibly displayed on the wrong dates.

As an example, I'm attaching a sample file generated with KOrganizer 3.5.x to be loaded with Europe/Vienna as the local time zone. If you look at the recurrence instances in KOrganizer 3.5 and 4.x, you'll see that they appear on different dates. This is one of the worst problems, because it means that you can no longer trust any date in your calendar!

The solution is to simply add a compat rule for files created with KOrganizer <= 3.x and convert all UTC times (at least for recurring incidences) to local time with the configured TZ attached. This way, the interpretation will be the same as in 3.5.
Comment 1 Denis Kurz 2016-09-24 18:44:30 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of korganizer (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 2 Denis Kurz 2017-01-07 21:37:56 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.