openerp-expert-framework team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

In order to be accurate, I have checked in this scenario:
- OpenERP 6.1 RC1,
- Client machine timezone: America, Buenos Aires, GMT-3
- Using WEB client

I have created a new sales order.
Sales order date: Feb 16, 2012
I have saved the order in draft state (just with the new date and a
customer)
In database, field date_order from sale_order => "2012-02-16" (note that
there is no HH:MM:SS)
I read again the newly created order => shown date: Feb 15, 2012

Reasoning: date was read, assumed in UTC, then GMT-3 is applied, new date
Feb 15, 2012 21:00:00 => date shown Feb 15th!

The same happens with default dates provided by the system, like the order
date on a newly created record (always a day before now!)

In any case, the most important concept to implement is the fact that dates
are timezone independant. Let's say we create an invoice in ARG (GMT-3)
with date Feb 16th, the same invoice should be read by a user in San
Francisco (GMT-7) with the same creation and due dates! It is a legal issue

Taking into account the previous explanation, and the fact that this
problem is present in any date entered in the system, I insist considering
this issue as critical

Thanks for your prompt answer and consideration


El 2 de febrero de 2012 10:28, Olivier Dony (OpenERP) <
925361@xxxxxxxxxxxxxxxxxx> escribió:

> On 02/02/2012 01:50 PM, Gustavo Adrian Marino wrote:
> > I fully agree with the concept that dates are timezone agnostic, and thus
> > they should be treated as a special case.
> > In the example given it is clear the current initialization code is not
> > storing HH:MM:SS in the database field. Is not possible to use that fact
> as
> > an indicator we are taking about a timezone agnostic date, a treated
> > accordingly on GTK and WEB UI?
>
> Sure, distinguishing the pure date fields from the regular datetime
> fields is easy: they are different field types, i.e. declared as
> fields.date(...) instead of fields.datetime(), and the client is aware
> of that when displaying them.
> So we can easily do the right thing for each type - the question is
> more: What is the right thing to do? ;-)
>
>
> > The problem is affecting every place in the system where you are
> recording
> > a date. Thus, and as an example here in Argentina, depending on the time
> of
> > the day, you set a date and magically is converted to the previous day!
>
> Hmm, this should only happen for dates that have been provided by the
> system, such as default PO date, etc. It should never happen for dates
> that a user would manually enter in a form, as long as the proper
> timezone is configured in the user preferences and matches the user's
> computer timezone.
> Can you confirm this is what you experience?
>
>
> > Let me say that this problem is a showstopper for any implementation. It
> > should be treated as a critical problem, that should be solved before
> > publishing the RC as an official version
> >
> > Please, consider a reevaluation of the priority
>
> We consider this a blocking issue for releasing 6.1 indeed. The new
> release will not be published until all Medium (and higher) bugs have
> been solved. But this issue only affects the system-provided default
> values, and users can manually correct those before saving the new
> records, so it is not exactly a form of data corruption. I would say it
> is a severe form of misleading and error-prone default values.
> I see no issue raising the priority to High if you insist, but at this
> point it will not change the way we handle the bug at all...
>
>
> Thanks everyone for the quick feedback!
>
> --
> You received this bug notification because you are a member of OpenERP
> Framework Experts, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/925361
>
> Title:
>   [6.1] date values that are initialized as 'defaults' may appear as
>  "off by one day" in some countries depending on the time
>
> Status in OpenERP Server:
>  Confirmed
>
> Bug description:
>   This issue was initially discussed on bug 918257. It always existed,
>  but was less apparent when addons and framework code were using a
>  timezone that was closer to the user's timezone.
>
>  As of 6.1 all addons and framework code is supposed to work
>  exclusively with UTC datetime values (as discussed on comment #4 of
>  bug 918257), and this means the problem will occur more often.
>
>  Basically, our main issue is that pure date value (without time) can
>  never be converted to different timezones, because depending on the
>  time they were recorded, the date may still be yesterday in some parts
>  of the world, or already tomorrow. Therefore OpenERP clients (Web &
>  GTK) cannot (and should not) perform date conversions when displaying
>  pure date fields.
>
>  Let me try to explain...
>
>  For datetime values, the conversion to the local timezone is easy to do.
> Let's say addons code uses the current time to set the value for a datetime
> field in a new record: 2012-02-02 08:56:00 AM (UTC+00:00).
>  The value is converted when it is displayed by the client and will
> unambiguously be 2012-02-02 09:56:00 PM in Auckland where the timezone
> offset is +13:00 at that time.
>
>  However when addons code works with dates (without time) to initialize a
> new record, this is what is stored in the database: 2012-02-02 (UTC+00:00).
> When that value is displayed to the user, no conversion of timezone can
> occur because the client has no idea at what time the date was in fact
> recorded!
>  2012-02-02 is correct for an Auckland-based user if the date is recorded
> before 11:00 AM UTC, but if recorded at 1:00PM it should be 2012-02-03,
> because Auckland has just passed midnight already. Web/GTK client cannot
> perform this conversion at all, and must display pure dates as stored in
> the database.
>
>  Now, I see a few reasonable options to fix this:
>
>  1. We could convert most date fields to be truly datetime fields in the
> database, and simply set the "display widget" to be a date widget, e.g.
>        <field name="order_date" widget="date"/>
>  The field would behave like it does currently, except that the client
> would have enough information to properly display the local date, as it
> would know at what time the date was recorded.
>
>  2. Alternatively we could provide a helper function in the framework to
> easily let addons code grab the current date value *as the client would see
> it*. Instead of initializing default values as we do now, i.e.:
>   _defaults = {
>     # Following gives 2012-02-02 even at 1:00 PM UTC
>     'order_date': lambda *a: time.strftime('%Y-%m-%d')
>   }
>  we would therefore do it using the user's timezone provided in the
> context, i.e something like this:
>   _defaults = {
>     # For users in Auckland the following would give 2012-02-02 until
>     # 11:00 AM UTC, and properly return 2012-02-03 afterwards
>     'order_date': lambda cr,uid,ctx:self._current_user_date(cr,uid,ctx)
>   }
>
>  I tend to favor the second option, which seems simpler and cleaner to me.
> That would basically mean we break the rule of using only UTC date and time
> values in addons, and consider that pure date values are timezone agnostic
> (which is really the case: a date without a time cannot be properly
> converted to another timezone, ever), or more exactly, that they are only
> valid in the timezone of the user who created that record.
>  Date computation would continue to work fine: adding/subtracting days
> would works as expected.
>
>  The main limitation with option 2 is that dates cannot would not be
>  displayed differently depending on the user's timezone. For
>  distributed teams, an invoice created by a user in Auckland on
>  '2012-02-03' would appear to be created 'tomorrow' for her colleague
>  in New York where the date is still '2012-02-02'. I think this is fine
>  and actually expected, we don't want the invoice to be 'floating'
>  between one day and the next.
>
>  Any opinions on this?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/925361/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>


--

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino

-- 
You received this bug notification because you are a member of OpenERP
Framework Experts, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/925361

Title:
  [6.1] date values that are initialized as 'defaults' may appear as
  "off by one day" in some countries depending on the time

Status in OpenERP Server:
  Confirmed

Bug description:
  This issue was initially discussed on bug 918257. It always existed,
  but was less apparent when addons and framework code were using a
  timezone that was closer to the user's timezone.

  As of 6.1 all addons and framework code is supposed to work
  exclusively with UTC datetime values (as discussed on comment #4 of
  bug 918257), and this means the problem will occur more often.

  Basically, our main issue is that pure date value (without time) can
  never be converted to different timezones, because depending on the
  time they were recorded, the date may still be yesterday in some parts
  of the world, or already tomorrow. Therefore OpenERP clients (Web &
  GTK) cannot (and should not) perform date conversions when displaying
  pure date fields.

  Let me try to explain...

  For datetime values, the conversion to the local timezone is easy to do. Let's say addons code uses the current time to set the value for a datetime field in a new record: 2012-02-02 08:56:00 AM (UTC+00:00).
  The value is converted when it is displayed by the client and will unambiguously be 2012-02-02 09:56:00 PM in Auckland where the timezone offset is +13:00 at that time.

  However when addons code works with dates (without time) to initialize a new record, this is what is stored in the database: 2012-02-02 (UTC+00:00). When that value is displayed to the user, no conversion of timezone can occur because the client has no idea at what time the date was in fact recorded!
  2012-02-02 is correct for an Auckland-based user if the date is recorded before 11:00 AM UTC, but if recorded at 1:00PM it should be 2012-02-03, because Auckland has just passed midnight already. Web/GTK client cannot perform this conversion at all, and must display pure dates as stored in the database.

  Now, I see a few reasonable options to fix this:

  1. We could convert most date fields to be truly datetime fields in the database, and simply set the "display widget" to be a date widget, e.g. 
        <field name="order_date" widget="date"/>
  The field would behave like it does currently, except that the client would have enough information to properly display the local date, as it would know at what time the date was recorded. 

  2. Alternatively we could provide a helper function in the framework to easily let addons code grab the current date value *as the client would see it*. Instead of initializing default values as we do now, i.e.:
   _defaults = {
     # Following gives 2012-02-02 even at 1:00 PM UTC
     'order_date': lambda *a: time.strftime('%Y-%m-%d') 
   }
  we would therefore do it using the user's timezone provided in the context, i.e something like this:
   _defaults = {
     # For users in Auckland the following would give 2012-02-02 until
     # 11:00 AM UTC, and properly return 2012-02-03 afterwards
     'order_date': lambda cr,uid,ctx:self._current_user_date(cr,uid,ctx)
   }

  I tend to favor the second option, which seems simpler and cleaner to me. That would basically mean we break the rule of using only UTC date and time values in addons, and consider that pure date values are timezone agnostic (which is really the case: a date without a time cannot be properly converted to another timezone, ever), or more exactly, that they are only valid in the timezone of the user who created that record.
  Date computation would continue to work fine: adding/subtracting days would works as expected.

  The main limitation with option 2 is that dates cannot would not be
  displayed differently depending on the user's timezone. For
  distributed teams, an invoice created by a user in Auckland on
  '2012-02-03' would appear to be created 'tomorrow' for her colleague
  in New York where the date is still '2012-02-02'. I think this is fine
  and actually expected, we don't want the invoice to be 'floating'
  between one day and the next.

  Any opinions on this?

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/925361/+subscriptions