openerp-community team mailing list archive

[Pedro Manuel Baeza Romero <pedro.baeza@xxxxxxxxx>]

Hi, Mario,

I agree that tz issues is a question to solve, but I don't think this is
very easy to handle or do it in a general way, because you can't set a
general rule to apply when something must be treated on UTC or in the user
tz. There is another technical question I see now in one of the issues you
comment: information on pivot tables (BI reports) are taken directly from
the DB (for performance reason), without no possibility of modifying some
things like these dates, that are saved on UTC format.

We can anyway contribute with fixes to each localized issue that can be
solved to speed up the process of removing them.

Regards.

2014-09-21 1:24 GMT+02:00 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
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>