+1 Mario On Sep 22, 2014 9:08 AM, "Mario Arias" <[email protected]> wrote:
> Hi Ferdinand, > > Problem is that any "period" that you define will suffer the same > problem. Datetimes at the very begining or end of any given period will be > placed in wrong one, accordingly to the timezone of the user and impact is > bigger as the timezone difference increases.... > > How can you explain a customer that their reports are not accurate because > Odoo must support companies with multiple time zones ? > They should be accurate for companies in a single time zone, and from > there move to work for multi time zone ones... Right now, it is not > working for any of them, unless your clients are in Europe... > > Again, if Odoo displays datetime fields adjusted to user time zone, then > filters on datetime should be adjusted accordingly... > > Then, defaults for date and datetime should be checked, to see if > time.strftime > is correct or should be changed to context_today calls (most calls should > use the later... ) > And finally, reports should be adjusted to use formatLang instead of plain > datetime fields... > > > Regards, > -Mario > > On Sun, Sep 21, 2014 at 11:01 AM, Ferdinand Gassauer <[email protected]> > wrote: > >> On 2014-09-21 04:35, Mario Arias wrote: >> >> My suggestion is to use periods (or weeks, trimester, fiscal years,...) >> for search. (only rare cases use the "DAY" as search criteria) >> odoo must guarantee that users in different time zones product the same >> results >> if not - Odoo can't be used in multi-timezone companies (or even >> switching to/from daylight saving may return different results around >> midnight) >> >> At display time, Odoo is translating all datetime fields to user >> timezone. >> >> The same should be true for filters... but it isn't. If we fix them, >> we would have covered a lot of current problems. >> >> Most others are just result of bad programming or old traces of code >> when datetimes were not in UTC, and them could be identified easily with a >> search in the code, like most (all??) time.strftime calls that should be >> replaced by fields.date.context_today, as the ORM/web client will translate >> them to UTC when saving to database... >> >> Same for reports, as all datetime fields should use formatLang to take >> care of time zone issues... >> >> >> All defaults for Date only fields should also be checked, as sometimes >> they are registered on "next day" or "previous day" relative to user that >> is creating the records, and that is legally wrong, besides messing up any >> reporting... >> >> I can go ahead and create a mega issue report with all wrong >> occurrences, or even go one by one... but at least would like to hear >> someone from S.A. confirming that is the way to go and that they will >> check, as so far this doesn't seem to be the case with most issues on this >> still open... >> >> >> Regards, >> -Mario >> >> >> On Sat, Sep 20, 2014 at 5:32 PM, Pedro Manuel Baeza Romero < >> [email protected]> wrote: >> >>> 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 <[email protected]>: >>> >>>> 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 >>>> >>>> >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> >> >> -- >> Ferdinand Gassauer >> Eigentümer >> ChriCar Bet. u. Ber. GmbH >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
