c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <711084@xxxxxxxxxxxxxxxxxx>]

@philu: 
Thanks for the detailed explanation! You're right, something wrong is happening with timezone conversions on Windows. However from my tests (win XP), it seems to be the same issue for GTK and Web client both, as soon as they are running on Windows (for the web client, keep in mind that what matters is where the Web Client Service is running, not the browser!).

The current logic is the following, which is close to what you suggested:
1. the server does not do any time conversion or offsetting, it treat all times and dates as if they are in its own timezone (i.e with no timezone info set), and stores them as such in the database
2. the clients (web and gtk both) are in charge of doing the conversion on-the-fly, displaying the local date/time info to the user (according to the timezone chosen in the user preferences), and sending/reading the values to/from the server in the server timezone
3. in order to do the conversion, clients need to know 2 timezones: the one of the user (set in user preferences) and the one of the server (returned by the server when you ask it)
4. if the client timezone is not set, all date/time info is displayed with no conversion, i.e. in the same TZ as the server
5. if the server cannot detect its own timezone to broadcast it (see tools.misc.get_server_timezone()), it defaults to "UTC"

I have tested with a server on Ubuntu which is in CET timezone and a user which is in the "Australia/Brisbane" timezone. When the clients are running on Ubuntu it works fine and the conversions happens as described above. But when the clients are running on Windows no conversion occurs and it displays the datetime info in the server timezone, just as if no timezone was set.
The reason, in my case, is really that the timezone info from pytz was not properly installed. By enabling the Web client error log file, I noticed the following typical traceback in the log (I expect GTK client to have the same ones):
[22/Feb/2011:12:33:03]  Error in timezone formatting:
Traceback (most recent call last):
  File "openobject\i18n\format.pyo", line 153, in format_datetime
  File "openobject\i18n\format.pyo", line 90, in tz_convert
  File "pytz\__init__.pyo", line 157, in timezone
UnknownTimeZoneError: 'Australia/Brisbane'

After correcting it and making sure that the "zoneinfo" folder was
really present in the pytz folder of my python libraries, the problem
was fixed and *both* GTK and Web behaved as they do on Ubuntu.

Therefore the root issue for your bug can only be one thing: the conversion is failing, either because pytz's zoneinfo data is really not properly reachable by the pytz module, or for another similar reason.
To pinpoint the issue you can enable the error log file in your Web Client Service running on windows (i.e by uncommenting the "log.error_file"' line in the doc/openerp-web.cfg, choosing a valid path, and restarting the service) to see the specific exception trace.

In the mean time, I will at least confirm this issue for the reason that
the pytz zoneinfo data is missing *again* in all windows packages

** Project changed: openobject-server => openobject-client

** Changed in: openobject-client
   Importance: Undecided => Medium

** Changed in: openobject-client
       Status: Triaged => Confirmed

** Changed in: openobject-client
    Milestone: None => 6.0.2

** Changed in: openobject-client
     Assignee: (unassigned) => OpenERP's Framework R&D (openerp-dev-framework)

** Summary changed:

- Timezone not taken into account by server, but web-client works perfectly
+ [6.0,trunk] pytz zoneinfo missing from windows packaging - timezone conversion not working

** Also affects: openobject-client-web
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/711084

Title:
  [6.0,trunk] pytz zoneinfo missing from windows packaging - timezone
  conversion not working

Status in OpenERP GTK Client:
  Confirmed
Status in OpenERP Web Client:
  Confirmed

Bug description:
  OpenERP server and web client 6.0.1 running on Ubuntu server (32-bit) 10.10
  Postgres 8.4
  Windows GTK client and web browser (Google Chrome) on WIndows 7 (64-bit)

  (Server and web client were set up as per
  http://powerphil.wordpress.com/2011/01/28/how-to-install-and-
  configure-an-openerp-6-0-1-server-and-web-server-on-an-
  ubuntu-10-10-server/).

  Problem is that the times shown in the GTK client are shown at GMT (unless the server's TZ environment variable is set), i.e. they ignore the user's Timezone preference.
  However, the web client works correctly.

  More details:
  Ubuntu server's time is correctly set to GMT. For example, if the time in London is 1am, the server's time also shows 1am (by doing a "date" on the command line, and the TZ environment variable is not set to anything).

  Both openerp-server and openerp-web processes are running without any
  TZ setting.

  Then log into OpenERP using a web browser; set the User's preference
  to Australia/Sydney; create a new Phone Call, Outbound; the time
  correctly shows 12 noon (GMT + 11 hours, Sydney currently being on
  summer time).

  Do the same in the GTK client; the time shows 1am - wrong; it should
  be 12 noon.

  ---------

  More information:

  So try to work around the problem: in the .bashrc file of the openerp user that runs the openerp-server process, set the TZ, viz:
  TZ='AEST-10AEDT-11,M10.5.0,M3.5.0'
  export TZ

  Restart the service; log into the GTK client; create a new phone call; the time now shows correctly (for the wrong reasons, admittedly).
  Go to the web browser and do the same thing; the time now shows 19 hours ahead of what it should be (on the next day!). Wrong.

  So it looks like the web client is taking timezone time into account,
  in addition to whatever the openerp-server is doing, and it should be
  the other way around: the openerp-server should be calculating the
  correct time, and the web server should just be presenting it.