Comment 10 for bug 1002733

Hello Yann,

This is indeed a limitation of OpenERP's recurring calendar events as of version 6.1. It may seem like a basic limitation at first, but it stems from some rather important technical reasons.

As of OpenERP 6.1 the management of date and time data has been drastically reviewed and cleaned up, in order to work properly in multiple timezones for international companies. Before 6.1, datetime data were not properly handled in many cases, and there were numerous ways to really corrupt them (via a simple server configuration change, a database migration, etc.)

The change is described in comment #4 of bug 918257, if you'd like to see the technical details. It is an industry-standard solution and the community agrees that it was the right thing to do.

As a result of this change, the date and time of calendar events is stored in the database in UTC timezone like for all datetime data. It will appear correctly to all users even in multiple timezones contexts, because the date is converted to the user's local timezone upon display. There is one exception to this: recurring events which span across DST limits. Because the event is stored in UTC, it is a fixed reference point without DST variations (e.g. 7:00 AM UTC is 9:00 CEST and 8:00 CET), and will therefore be offset by 1 hour after the DST change.

In order to correct this we would need to store the "floating timezone" of the user who created the recurring event (e.g. Europe/Paris), and apply a fictitious offset of one hour to the stored UTC time when DST applies in that timezone. This requires complex date manipulation and precise knowledge of DST switch dates, which does not always exist. For instance in Morocco the DST date is different every year and is decided only a few months in advance according to the Ramadan schedule - there's no chance the software will know exactly when that DST switch is supposed to happen.
As you see, solving this would require complex assumptions and would still lead to errors in some cases.

When you contrast this with the very simple workarounds of dividing your year-long recurrent event into 2 separate events offset by one hour, or simply updating the recurrent event after a DST switch manually, writing that solution in the software really looks like a nice-to-have feature. We would certainly implement it given unlimited resources, but we have more important features to work on at the moment.
The other pieces of software that support it probably implement custom handling for calendar events, and certainly have limitations in international context, for example when it comes to ill-defined DST switch dates.

We're sorry for the inconvenience, and we know it kind of worked before v6.1, but this was at the cost of much more important sources of errors. We might consider improving this in a future version, and will of course appreciate it if anyone in the community wants to work on a patch.

I hope you understand the reasons behind this choice...