Technical mailing list archives
RE: TZ in Odooby
I don’t think explicit TZ information should be stored in the database for this situation.
Instead the location should be stored in the DB, and then the viewing user could choose between viewing it in their local TZ, or the TZ associated with the scheduled location (or perhaps an entirely separate locations timezone).
It’s possible for timezones to change for a particular location (normally due to political reasons… like the annexing of Crimea changing their TZ), which if using fixed TZ information wouldn’t be captured.
A UI layer that can do UTC -> location specific time conversion would be of most value here.
From: Manuel Vázquez [mailto:firstname.lastname@example.org]
Sent: Tuesday, 14 July 2015 2:30 AM
To: Community: Framework
Subject: Re: TZ in Odoo
AFAIK, datetimes are stored in the DB using UTC. Again, I'm only
starting to dig through all the code where TZ seems to be involved right
now, but so far it seems Odoo behaves as you say: UTC in the DB. So I
won't elaborate further on this matter.
What it seems to be missing, however, is a way to communicate which TZ
should a particular datetime is to be presented to the user. Using the
TZ of the browser is not the right choice all the time. It certainly
covers most of the use cases, but not no all.
Yes, TZ are hard, but they are unavoidable in some scenarios. My users
are getting confused when they receive a travel plan that includes
breakfasts at 2AM (local time), whenever who is making the plan is 6
hours ahead. Step by step:
- The plan maker, who is at Paris, says the breakfast should take place
at 8AM (but he has no way to say it will happen at Havana, thus Havana
- The Havana crew gets a breakfast planned at 2AM.
As of today the plan maker would have to type 14PM so that the breakfast
gets properly schedule at 8AM (Havana time).
What I think should be provided is way to make a datetime field (at the
UI level) TZ-aware. Probably:
- Show the TZ to the user.
- Let the server indicate a TZ for display purposes only.
That way a TZ-sensitive field could be encoded in a pair of datetime,
tzinfo columns in the DB. The first column would remain UTC, but the
tzinfo could be fed to the UI layer for proper representation.
Le 13/07/2015 09:38, Bevan Weiss a écrit :
> 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.
> Bevan Weiss
Post to: mailto:email@example.com