Community: Framework mailing list archives
RE: TZ in Odooby
I believe with this, the best solution is to have all dates and times within the DB be in UTC.
It’s only when presented to the user that a TZ should then be attached to the dates and times.
Timezones are too confusing otherwise… what happens if the DB ends up in a timezone which has daylight saving time? If the DB has a datetime which is the daylight saving shift, what should the other non-DST people interpret the time as? For us here in Australia, on one day of the year there is no 2am (it skips from 1:59am through to 3:00am), another day of the year we get two sets of 2:59am (it skips back to 2:00am at 3:00am that day).
I’m not sure if this has been cleanly implemented through-out the Odoo database however (I suspect not)
I believe DB in UTC would respect your use cases. For standard usage the view interface would convert from UTC to localtime.
Then for a particular situation where you care about an alternative TZ (like your Fiji example) it would be possible to view things in this TZ (entry and display would be converted here).
Things like calendar appointments could even be shown as multiple timezones (so that you can plan a meeting time which is suitable for multiple people in different timezones), just by applying the appropriate offsets from the UTC that the DB will record everything as.
From: Manuel Vázquez [mailto:email@example.com]
Sent: Monday, 13 July 2015 11:18 PM
To: Community: Framework
Subject: TZ in Odoo
I kept experimenting a bit longer... It seems Odoo does not take the
user's configured TZ into account when showing datetimes.
- AJAX calls return datetime values as they are in the DB.
- The UI is the one chosing to represent those values in the TZ of the
This makes sense for many use cases. However it poses a challenge when
your use case conveys explicit timezone information: Two people in
different timezones coordinating a future event that will occur in a
third TZ may require both see the same datetime in the TZ where the
event will occur.
For instance, my family and I live 3 timezone hours apart, we're
planning to make a trip together to Fiji, when we're there we'll share
the same TZ; so when I say let's dinner at 7PM this time is naturally
Fiji time and not whatever time will be in Fiji when is 7PM at my place.
This is tricky, though. If two people are coordinating an event, but
they will be attending it from its current TZ (ie. a phone call) they
surely need to see the event in their TZ.
Grepping the sources I've found a lot places where there are tz
calculations. Some of those are at the DB level, but I still don't know
when they are called.
Le 11/07/2015 05:21, Levent Karakas a écrit :
> Since you don't have user context in workflows, you don't have
> timezone and language setting. Not only tz but also translation is not
> possible as well.
Post to: mailto:firstname.lastname@example.org