As of OpenERP 6.1 the server timezone is forced to UTC in order to remove any ambiguous timezone/DST conversions, and make sure the database content is fully portable. All timezone conversions are meant to be performed on the client-side from now on. This was further explained in bug 918257 (especially comment #4) and the further technical discussions in bug 925361.
It appears that the manner in which we force the UTC timezone[1] does not work under Windows, probably because the Python implementation of the time module has some limitations on this platform (such as not supporting time.tzset()[2,3]).
As a result, the server will actually operate in the natural OS timezone, while thinking it is using UTC values. As a result, the offset from UTC may appear to be applied twice when displayed on the client-side.
It seems we must modify the OpenERP-Server-Service environment before startup to fix the issue. This can be done by adding an "Environment" registry value to the registry key defining the OpenERP-Server service, and then restarting the server.
The attached registry patch (fix_tz.reg) should accomplish this. In case it goes wrong, a second registry patch is provided to undo the change (undo_fix_tz.reg).
Any feedback on this registry patch from Windows users is greatly appreciated!
The next step is to integrate this registry patch in our All-In-One installer for Windows. The NSIS API provides ways to write to the registry, unfortunately we need to write a REG_MULTI_SZ (i.e. hex(7) type, as see in the registry patch), and this is not supported by the NSIS API.
This forum thread discusses a manual implementation of REG_MULTI_SZ in NSIS scripting, but seems overcomplicated/overkill for our simple patch: http://forums.winamp.com/showthread.php?t=172312
Perhaps we should simply include the .reg patch in the installer and merge it during installation (to be investigated)
Note: OpenERP servers deployed on a Unix platforms are not affected by this issue. It is always recommended to deploy the server on Unix, as a lot of maintenance tasks will be greatly simplified: configuration file editing, log analysis, patch deployment, etc. End-users can of course use the system from their Windows desktops, so this is usually not a problem in most companies. Deploying the system in a virtual machine running on a Windows host is also a workable solution.
[1] Setting os.environ['TZ'] to 'UTC' at server startup
[2] http://docs.python.org/library/time.html#time.tzset
[3] http://stackoverflow.com/questions/4360981/make-python-respond-to-windows-timezone-changes
No effect
is still wrong