Comment 4 for bug 918257

Hi,

I don't think this is a bug, and to get matters straight, here is a description of how timezone support is designed to work in OpenERP 6.1 (quite different from 6.0 and earlier):

1. Framework/Addons python code
OpenERP 6.1 now uses exclusively UTC timestamps for server-side computations and storage. At startup the server forces the Python timezone to be UTC, so that any call to datetime-related modules will always use UTC by default. As Xavier said the server exchanges UTC timestamps with clients, and the timezone-specific rendering is only ever done on the client-side.
The only case where the Timezone setting of the user preferences matters is for reports, because the rendering is performed server-side, so the user timezone needs to be applied. This is supported by formatLang(), a function available inside reports for rendering date time values.

2. Timezone-specific rendering in clients
* GTK client will render the datetime values according to the "Timezone" configured in the user preferences. If no timezone is selected, it will display datetime values in the server-side timezone, i.e. UTC.
* Due to Javascript's limited native timezone capabilities, the 6.1 web client cannot apply the "Timezone" that is set in the user preferences, and thus always renders value in the local timezone of the browser (which should usually be a sensible choice). The user timezone setting still matters for reports, as explained in 1.

3. Database storage
Datetime values are also exclusively stored as "timestamp without timezone" in the database, so Postgres will never alter the values, and they will be handled as UTC all the time. We also don't use "select now()" at DB level for initializing new record values, that would require an unnecessary db query - datetime.datetime.now() or time.strftime() work well enough for us.
In the few cases where we need to use now() (e.g. for WHERE clauses comparing with the current time) we now use "now() at time zone 'UTC'". The timezone of the DB connection is therefore irrelevant by design.

These 3 rules seem to explain the behavior described in the bug description: the datetime values are stored as UTC and displayed in the web client using the local browser timezone, which is apparently not UTC - this is the expected behavior.
You will usually get the expected behavior in all OpenERP clients if you properly set your local browser timezone (OS user timezone by default), and set the same timezone in the User preferences (for reports and GTK).

This is the intended design, there might of course be some left-over cases where these rules are broken, but there should not be that many (e.g. missing `formatLang` calls in reports, etc.). These would be bugs and we are fixing them as we find them

We'll also add a tooltip on the Timezone user preference field to explain this, and include the above explanation in the release notes and developer documentation.

Please reopen this bug (or a new one) if you notice a case that does not seem to match the above rules.

Thanks,