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) <
<email address hidden>> 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     : <email address hidden>
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: <email address hidden>

Skype: gustavo.adrian.marino