Comment 4 for bug 925170

I've had a look further at this, and it is for any date field, or indeed
just any calculation involving a date. It is most obvious with defaults,
but appears universal in that if you have a datetime object (such as the
servers time, but any datetime object), it is first converted to a date
then to local timezone. This is of course the wrong way around. It should
be calculated first as datetime without timestamp, then converted to local
timezone and then converted to date.

Or else the only other reasonable solution is to convert all date fields to
store as UTC datetime but display as a date client side after conversion.

btw, this might seem low priority issue to you, but anyone on the West
Coast of the US right around to Australia and China is going to go mental
with this. These dates are used everywhere. It even cause ir.cron to
chuck an error when scheduling next calls before 1pm.

On Thu, Feb 2, 2012 at 10:19 PM, Amit Parik (OpenERP) <email address hidden>wrote:

> ** Changed in: openobject-addons
> Assignee: OpenERP R&D Addons Team 3 (openerp-dev-addons3) =>
> (unassigned)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/925170
>
> Title:
> [addons][trunk] timezones aren't being applied correctly
>
> Status in OpenERP Addons (modules):
> Confirmed
>
> Bug description:
> Timezone is Pacific/Auckland - UTC+13 currently
>
> Client is set to correct timezone, as is host.
> Also tested on web-client
>
> Now if a Sales Order is created before 1pm it is dated as yesterday.
>
> The problem seems to be that when calculating the date it uses the
> servers current time (UTC) and not the clients.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/925170/+subscriptions
>