[6.1] Recurrent events do not properly support crossing DST boundaries

Bug #1002733 reported by Yann Papouin
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Confirmed
Wishlist
OpenERP's Framework R&D

Bug Description

Create a new meeting with these settings:

- Start at : 08:00:00
- Finish at : 10:00:00
- Recurrency period: Weekly
- Repeat every : 1
- Recurrence termination : End date
- Repeat Until : 12/26/2012
- Choose day where repeat the meeting : [x] Wednesday

Now, browse to October Month, when the daylight saving applies:
An offset of one hour is applied to the meeting instanced (see screenshot attached), that 's not correct.

note: that's obvious that your country must apply daylight saving to see this, to me it's France.

Revision history for this message
Yann Papouin (yann-papouin) wrote :
Revision history for this message
Ravish(OpenERP) (rmu-openerp) wrote :

Hello Yann,

I have checked your issue. But It's working fine for me.
For your reference ,I have attached shot.Please take a look

Thanks!!!

Changed in openobject-addons:
status: New → Incomplete
Revision history for this message
Yann Papouin (yann-papouin) wrote :

What 's your server's country ? Your Timezone ?

Revision history for this message
Yann Papouin (yann-papouin) wrote :
Revision history for this message
Yann Papouin (yann-papouin) wrote :

May it be related to a python time management library version ?

Revision history for this message
Ravish(OpenERP) (rmu-openerp) wrote :

Hello Yann,

I have tested with Timezone Europe/Paris. and Python version 2.6.
Are you taking about dateutil library version..???

Thanks!!

Revision history for this message
Ravish(OpenERP) (rmu-openerp) wrote :

or pytz...??

Revision history for this message
Yann Papouin (yann-papouin) wrote :

I don't really know, I'm using Ubuntu 10.04 and the python-dateutil version is 1.4.1-3
I'm pretty sure it's related to the OS timezone.

Can you try dpkg-reconfigure tzdata and select "Europe" and restart your server to see if it's relevant ?

Revision history for this message
Yann Papouin (yann-papouin) wrote :

Did you test it ?

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

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

Changed in openobject-addons:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Wishlist
status: Incomplete → Confirmed
summary: - [6.1] Invalid calendar recurrency with daylight savings
+ [6.1] Recurrent events do not properly support crossing DST boundaries
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.