← Back to team overview

openerp-community team mailing list archive

Re: General problems with datetime fields and time zones...


On 2014-09-22 05:38, Mario Arias wrote:

what I was trying to say:
if a user with time zone New York and another with Paris in their odoo profile calls the same report for July 2014 it must return the same data
so if the "period_id" is stored in the data it's easy.

probably this is what "context_today" does.

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...


On Sun, Sep 21, 2014 at 11:01 AM, Ferdinand Gassauer <office@xxxxxxxxxx <mailto: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
    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

    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...


    On Sat, Sep 20, 2014 at 5:32 PM, Pedro Manuel Baeza Romero
    <pedro.baeza@xxxxxxxxx <mailto: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.


        2014-09-21 1:24 GMT+02:00 Mario Arias
        <the.clone.master@xxxxxxxxx <mailto: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...


            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
            <mailto:the.clone.master@xxxxxxxxx>> wrote:


                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

                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...


            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  <https://launchpad.net/%7Eopenerp-community>
    Post to     :openerp-community@xxxxxxxxxxxxxxxxxxx  <mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe :https://launchpad.net/~openerp-community  <https://launchpad.net/%7Eopenerp-community>
    More help   :https://help.launchpad.net/ListHelp

-- Ferdinand Gassauer
    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

Ferdinand Gassauer
ChriCar Bet. u. Ber. GmbH

Follow ups