If the server located in timezone 'CST', the pytz.timezone will return error

[digitalsatori(Shine IT)]

This error can happen anywhere in the GTK code where the pytz.timezone(rpc.session.timezone) is used to get the server's tzinfo.
As the openerp server use 'time.tzname' to return the timezone name, when the server is located in 'CST' time zone, pytz.timezone('CST') will cause error.

[digitalsatori(Shine IT) (digitalsatori)]

the 'time.tzname' used in web_services.py is not a reliable way to get the time zone info. For example, on Windows Chinese version, it will even return Chinese characters.

[snook (snook)]

Getting the same error for current stable from the GTK Client.

Any progress on this ?

---------------------------
Traceback:

  File "/home/erp/openerp/client/bin/widget/view/tree_gtk/parser.py", line 313, in get_textual_value
    szone = pytz.timezone(rpc.session.timezone)
  File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 151, in timezone
    raise UnknownTimeZoneError(zone)
pytz.UnknownTimeZoneError: 'WST'

--------------------------
Python value returned from time:

Python 2.5.4 (r254:67916, Sep 20 2009, 10:05:43)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname
('WST', 'WST')

---------------------------
OpenERP setup:

Ubuntu 9.10

Server and client running python2.5

bazaar install

server @revison 1914
client @revision 1028

[Olivier Dony (Odoo) (odo-openerp)]

Determining the local timezone accurately is apparently non trivial in Python, taking into account the duplicate DST abbreviations ('EST' exists in 3 different locations with 3 different offsets from UTC) , the random timezone names used in Windows systems, etc.
However this issue is serious and causes a lot of bugs in the client when time offsets need to be calculated (the problem is actually very frequent on Windows systems, for example on Vista/Seven the tzname (DST) returned for CET is 'Madrid, Brussels')

A few links:
 * http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/
 * https://bugs.launchpad.net/zope2/+bug/142148
 * http://code.google.com/p/python-datetime-tz/source/browse/trunk/datetime_tz.py?spec=svn5&r=5#102

[Cloves Almeida (cjalmeida)]

The right way to do it seems to be plataform specific.

bin/service/web_services.py:timezone_get should return the contents of
'/etc/timezone'

Win32 seems to have a

import win32timezone
win32timezone.GetLocalTimeZone()

that returns a tzinfo object which we could extract timezone.

Olivier Dony (OpenERP) escreveu:
> Determining the local timezone accurately is apparently non trivial in Python, taking into account the duplicate DST abbreviations ('EST' exists in 3 different locations with 3 different offsets from UTC) , the random timezone names used in Windows systems, etc.
> However this issue is serious and causes a lot of bugs in the client when time offsets need to be calculated (the problem is actually very frequent on Windows systems, for example on Vista/Seven the tzname (DST) returned for CET is 'Madrid, Brussels')
>
> A few links:
> * http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/
> * https://bugs.launchpad.net/zope2/+bug/142148
> * http://code.google.com/p/python-datetime-tz/source/browse/trunk/datetime_tz.py?spec=svn5&r=5#102
>
>

[snook (snook)]

Google code project "python-datetime-tz" as mentioned above looks like a nice approach that says is compatible with "pytz."

http://code.google.com/p/python-datetime-tz/

[Olivier Dony (Odoo) (odo-openerp)]

A low-risk fix has been commited for the client in stable/5.0, just to avoid tracebacking when the server timezone is not recognized (web-client already handled this gracefully). The fallback method when it fails (i.e. when the user has a TZ set in the preferences, but the server-advertised TZ is not recognized) is to consider that the client is located in the server's TZ.
(rev: <email address hidden>)

As for the proper fix in trunk, here's what I plan to do:
- To avoid all sorts of risky migration operations, we won't attempt to explicitly store all timestamps in UTC, which would be a valid solution to the general timezone issue
- Storing the timestamps in the server's TZ also has the interesting property of allowing easy import/export of time data directly from the database in an intuitive timezone
- To limit the timezone detection headaches, we will try a basic identification, but provide mechanism to set the timezone manually by providing a server-side config option (TZ env variable and explicit config option). We will also keep using time.tzname when it contains a valid value, and finally default to UTC if all else fails (with a warning).
This should be reasonably backwards compatible while providing a flexible way of correcting the server's timezone.
- On the client side, we need to unify the time offset calculation, which is currently split all over the place

[Cloves Almeida (cjalmeida)]

Please, load timezone info from /etc/timezone on Linux, time.tzname[0]
is bogus. Mine returns 'BRT' and pytz.timezone('BRT') raises an exception.

Olivier Dony (OpenERP) escreveu:
> A low-risk fix has been commited for the client in stable/5.0, just to avoid tracebacking when the server timezone is not recognized (web-client already handled this gracefully). The fallback method when it fails (i.e. when the user has a TZ set in the preferences, but the server-advertised TZ is not recognized) is to consider that the client is located in the server's TZ.
> (rev: <email address hidden>)
>
> As for the proper fix in trunk, here's what I plan to do:
> - To avoid all sorts of risky migration operations, we won't attempt to explicitly store all timestamps in UTC, which would be a valid solution to the general timezone issue
> - Storing the timestamps in the server's TZ also has the interesting property of allowing easy import/export of time data directly from the database in an intuitive timezone
> - To limit the timezone detection headaches, we will try a basic identification, but provide mechanism to set the timezone manually by providing a server-side config option (TZ env variable and explicit config option). We will also keep using time.tzname when it contains a valid value, and finally default to UTC if all else fails (with a warning).
> This should be reasonably backwards compatible while providing a flexible way of correcting the server's timezone.
> - On the client side, we need to unify the time offset calculation, which is currently split all over the place
>
>

[Olivier Dony (Odoo) (odo-openerp)]

Ok, proper fix is commited in trunk as well:
 - openobject-client rev. 1077 - <email address hidden>
 - openobject-server rev. 1975 - <email address hidden>

It does consider /etc/timezone now, but only if no explicit timezone is set in the config (there's a new 'timezone' option), if the backwards-compatible method fails (that is, time.tzname[0] does not contain a valid timezone), and if is no TZ environment variable or if it does not contain a valid timezone either.
It also does a basic lookup in the windows registry for the current timezone, but short of having a full conversion table between Windows' "standard" timezones names and the Olson timezones used by pytz, it's very unlikely to work.

Anyway, the 'timezone' config option should now provide a clean solution for everyone if the default does not work.
I will update the doc about it.

PS: it finally defaults to UTC if everything fails, with a warning in the server log.

[digitalsatori(Shine IT) (digitalsatori)]

Great, the resolution to the problem looks very complete.

There is an typo in the code:

At line 1243, it should read: "sources.append((get_win32_timezone(),"Windows Registry"))" instead of "sources.append((get_win32_tz(),"Windows Registry"))"

[digitalsatori(Shine IT) (digitalsatori)]

The code fix at the client side didn't fix this problem: https://bugs.launchpad.net/openobject-client/+bug/503624

[Olivier Dony (Odoo) (odo-openerp)]

Thanks for the feedback digitalsatori, I fixed the typo (in rev. 1977) and will look into the issue of bug 503624.

[Olivier Dony (Odoo) (odo-openerp)]

Sorry about the ridiculous typo, still wondering how my editor silently reverted half of my refactoring of the method name...

From what I can tell reading bug 503624, it does not seem to be a regression due the current bugfix, but rather an old regression due to rev 990.1.6>996, and introduced by the "fix" for bug 434068.
As it was Jay who checked in 990.1.6, I'd ask him to review bug 503624.