openerp-community team mailing list archive

[Robin Bahadur <robin.bahadur@xxxxxxxxx>]

+1 Mario
 On Sep 22, 2014 9:08 AM, "Mario Arias" <the.clone.master@xxxxxxxxx> 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 <office@xxxxxxxxxx>
> 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 <
>> pedro.baeza@xxxxxxxxx> 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 <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
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> --
>> Ferdinand Gassauer
>> Eigentümer
>> ChriCar Bet. u. Ber. GmbH
>>
>>
>
> _______________________________________________
> 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
>
>