Yes, and that is why odoo uses in some places fields of type date. That,
together with a good default value from context_today, will ensure that
reports are consistent.
Problem is that in most places, there are only datetime fields, or date
fields that default to time.strftime (not considering cr
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 "contex
+1 Mario
On Sep 22, 2014 9:08 AM, "Mario Arias" 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
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
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-tim
Mario, regarding this datetime issue on search/filter views, maybe the
link below could help. I posted this some time ago on the OpenERP 6.1
GTK client repo, but the problem is the same. Unfortunately, right now I
have no time to look for equivalent code for Odoo (which I presume
should be in J
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, an
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 issu
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.
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, th
10 matches
Mail list logo
