[Openerp-community] General problems with datetime fields and time zones...

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Openerp-community] General problems with datetime fields and time zones...

Mario Arias
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Mario Arias
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Pedro Manuel Baeza Romero
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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Mario Arias
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp




_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Jordi Llinares
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 JS). Anyway, I hope it helps to point in the right direction.

https://bugs.launchpad.net/openobject-client/+bug/1253131

Jordi Llinares


El 21/09/14 a las #4, Mario Arias escribió:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Ferdinand Gassauer
In reply to this post by Mario Arias
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Mario Arias
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Robin Bahadur

+1 Mario

On Sep 22, 2014 9:08 AM, "Mario Arias" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Ferdinand Gassauer
In reply to this post by Mario Arias
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...


Regards,
-Mario

On Sun, Sep 21, 2014 at 11:01 AM, Ferdinand Gassauer <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
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     : [hidden email]
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openerp-community] General problems with datetime fields and time zones...

Mario Arias
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 creator user's timezone), and that breaks consistency.  You find this in POS, events, HR, ...

So we have two cases:
  • A "multi time zone" company, that needs ALL reporting that does grouping by date to use "DATE only" fields fro grouping/filtering.
  • A "single time zone" company, that only needs consistent adjustment of datetime fields AND filters across views and reports...

I am sure that a big majority of Odoo users belong to second option.  Besides, adding date only fields to models with problems is not an option under "stable no model change" policy, so I guess the only option we have for v7 or v8 is fixing filtering to consider user timezone, and create extra modules to fix problems to our clients that belong to case 1...

Maybe for v9 Odoo could add date fields, so case 1 finally works out of the box...

Regards,
-Mario

On Mon, Sep 22, 2014 at 12:22 AM, Ferdinand Gassauer <[hidden email]> wrote:
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...


Regards,
-Mario

On Sun, Sep 21, 2014 at 11:01 AM, Ferdinand Gassauer <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
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     : [hidden email]
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Loading...