openerp-community team mailing list archive

[Mario Arias <the.clone.master@xxxxxxxxx>]

If you check githut or LP, you will find a many issues reported about time
zone problems, and most of them are not solved, as a quick search on github
shows...

https://github.com/odoo/odoo/issues/2482
https://github.com/odoo/odoo/issues/2199
https://github.com/odoo/odoo/issues/2115
https://github.com/odoo/odoo/issues/1897
https://github.com/odoo/odoo/issues/1349
https://github.com/odoo/odoo/issues/822
https://github.com/odoo/odoo/issues/1108.
.
.
.

If we keep trying to fix those as isolated issues, we will never finish...
We need to address this at the ORM / web server level...



On Fri, Sep 19, 2014 at 6:02 PM, Mario Arias <the.clone.master@xxxxxxxxx>
wrote:

> Hi,
>
> Problems with datetime fields and time zones are everywhere in Odoo...
>
> They hit users in America and Asia/Africa harder , as our time zone
> differences are bigger than for users in Europe...
>
> As an example, take a user in GMT-6:00.
>
> Create  a POS order on 2014/08/31  after 18:00 local time, the pos order
> will have a database timestamp of next day:  2014/09/01...
>
> Create  a POS order on 2014/09/30  after 18:00 local time, the pos order
> will have a database timestamp of next day:  2014/10/01...
>
> Then, if we go to POS order analysis, and break results by month,
> timestamps get correct adjustment and show on right month.  So far so
> good...
>
>
> Then, if current date is somewhere in September, before  2014/09/30 18:00
> local time, and we turn on current month filter, errors arise...
> You will see the order from previous month and the one register in october
> will be gone...
>
> Even worse, if current date is 2014/09/30 18:01 or more, we will only see
> the order with timestamp of october, and it will show with date of
> september... !!
>
>
> Why, because the filter is not adjusted to take into account the user time
> zone... !!
>
> Even more evident if your users ask to break data by day....  Daily sales
> reports will never match with real sales... !!
>
> In regular sales this is not a problem, because invoice documents have a
> DATE (not DATETIME) so there is no room to adjustments, but in every other
> document that have a full timestamp, this problem is present...
>
>
> We could go on and try to open an Error Report for each, but I think this
> deserves an integral solution, not patches as has been done so far...
>
>
> I tried to locate the source to this, but this lays deep in the server
> and/or web service, and I definitely don't know the code enough to propose
> changes there...
>
>
> S.A. and community  experts, please join this thread and help fix this
> problem once and for all...
>
>
> Regards,
> -Mario
>