Comment 4 for bug 711084

@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