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 <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.
Regards.
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...
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
<mailto: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
<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
_______________________________________________
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
