[9.0/10.0/11.0/12.0] Calendar: The Changeover between summer and winter times is handled incorrectly.

[schmidtwastl]

For Example:
If you want to generate recurrent meetings every monday at 9 .a.m. they will swicth to 10 a.m. for all dates after 2016-03-27 and so on..

All Events after 2016-03-27 will have a wrong starting time.

[sysadminmatmoz]

I can confirm that the same time issue applies for the version 8.

[Frei7777]

Odoo v8: Is the same in both changeovers from summer to winter (-1 hour) and opposite (+1 hour).

[morphace]

That one is really annoying...

[Robx64]

That's serious PIA if you creating a long term events or bookings. I tested it in both 8 and 9. Weird that nobody spotted it before ? (I did ... about month ago.)

[Tito1337]

Does anybody have a patch for this? Thanks

[spadae22]

The crons time changes also, v8. @odony I hope this can be fixed asap. This is a bug.

[askz]

Still no fix?

[Yenthe666]

@JKE-be can you have a look at this please?

[rousseldenis]

Confirmed in v7 and v8 for cron jobs (we changed time this weekend...)

[Yenthe666]

Tested and confirmed in V10 too now. This issue has been open for 1.5 years and is now confirmed over three versions.
@odony perhaps it is time to look at this one? (sorry for the ping)

[feketemihai]

@Yenthe666 We had the same discussion a few days ago, on OCA/hr#307, i agree it's a little bit tricky the part with timezones, but we can always have the timezone of the server and start from there with "tm_isdst" from python datetime...

[gokhanerdogdu]

I wonder why this is not solved for a very long time. Is this something that will affect some base features?

[dreispt]

The robust fix for this would be to have timezone aware dates stored on the server.
That's a major change/addition to the ORM, but will makes it a trivial issue for Addon modules.

[dreispt]

@lasley This probably is a concern for you.

[hbrunn]

I'm considering adding local time zone support to https://github.com/OCA/server-tools/tree/8.0/field_rrule#repetition-rules - given the rrule is persisted as a serialized field basically, this should be doable by having two flavors of rrule fields, one that persists a naive utc datetime as it does now, one that persists a datetime localized to the time zone the user filled in. Then the developer can choose the appropriate one for the current use case, and the rrule library takes care of the rest. Then have the module yield utc datetimes, and the developer doesn't have to think about this issue at all save for picking the right flavor of the rrule field in the first place

[pedrobaeza]

@mart-e are there any plans to include something about this? Maybe to have into account DST corrections?

[mart-e]

@kujiu is it something you are working on in your work on timezones ?

[kujiu]

I didn't do anything on rrule field. It just serializes as always, but all datetimes will be timezoned in python code. The timezone is not encoded when serializing and the datetime is converted to UTC, so this problem is not solved. I think the fix will be minor as a different format for datetime can be store, and the convertion to cache use a smarter from_string method (it can convert more formats than just the DEFAULT_DATETIME_SERVER_FORMAT). I only changed date and datetime fields to return date and not-naive datetime instead of strings.

[pedrobaeza]

So maybe you can plan a task for this?

[Yenthe666]

@kujiu has there been any update in this?

[pedrobaeza]

Can anyone confirm if this is happening also in v12?

[JKE-be]

@pedrobaeza

Seems like some colleague try to fix it pr-27985

but tbh, I don't really follow the changes done in calendar anymore.

[dreispt]

Link: #27985

[nim-odoo]

Good! Now that EU is saying goodbye to daylight time saving, we'll have it fixed!

[Yenthe666]

@nim-odoo untill they start implementing different timezones for different countries within the EU. Then you'll have some extra fun again.

[BIARInc]

Related issue: when importing data from a CSV file, date time fields are changed. For example:
3/15/2017 1:20 am will stay 03/15/2017 01:20:00
4/1/2017 1:20 am will become 04/01/2017 02:20:00

Odoo 12.0

[luisiniguezh]

@pedrobaeza I can confirm that it is still happening on v12, can the 12.0 label be added to this issue?, I can work on the solution

[pedrobaeza]

Isn't #29293 handling it?

[luisiniguezh]

@pedrobaeza that's for v10.0 I'm working on fixes for 11.0 and 12.0

[pedrobaeza]

OK, I assume then the fix is not the same.

[luisiniguezh]

I still haven't checked the code on v11 and v12 to see if it is the same I'll do it after the v10 version gets merged to the OCA repository

[pnajman-modoolar]

Hi guys, we still have issues with this in 12.0 and now in 13.0 as reported in the following issue 45661

Can somebody take a look at this and add label 13.0 ?

[l-arnold]

I was able to work through my issue with Odoo 8.0 this specific problem with the following. I do not know how long the problem was running but expect since either "Daylight Savings time" came in, or since I set up a new (secondary) client machine that was not synching quite correctly (It was in the correct time zone but had was off for an hour before I changed the switch).
The issue though was consistent across 3 of 4 browsers, Odoo sensing that my Browser time was not synched with my Odoo Time.

Fix for me came from changing my Odoo USER time from America/Denver to America/Los_Angeles. The error went away. I followed by resetting it to Denver. The error returned (both in the header and in time logs).. However it seems I just refreshed the page a few times and errors, in the correct time zone went away.

I am red/green color blind and did not notice the Red Alarm signal in the header till I started trying to debug the issue I had noticed in the timeclocks.

My impression is that resetting my USER Time Zone, first away, then back caused Odoo to refresh its understanding of the situation.

I do not synch Odoo with external calendars but I am sure it would have been problematic there as well. Is a real issue with Time Logs if you are not looking at the 24Hour clock, just the specific minutes as was my situation.

[yajo]

I just opened #66754 which I think might be related to this problem. Please check it out.