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.
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.
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.