openerp-community team mailing list archive
Mailing list archive
Re: General problems with datetime fields and time zones...
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
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>
> 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
> 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...