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 <[email protected]> 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 : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
