© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Olivier:
Installed versions:
- server: 4004
- addons: 6432
- openerp-web: 2105
- client: 2040
Still the same behaviour
El 3 de febrero de 2012 06:45, Olivier Dony (OpenERP) <
<email address hidden>> escribió:
> On 02/02/2012 04:59 PM, Gustavo Adrian Marino wrote:
> > 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
>
> Do you mean 6.1 RC1 or the latest 6.1 trunk (*after* RC1)?
> If you're still using RC1 you're certainly seeing bug 922065, which was
> causing date fields to be converted upon display in the web client when
> they should really never be (conversion is for datetime fields only, as
> already discussed at length).
> Please upgrade the web client to any version later than rev.2067.
>
>
> > 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
>
> That would typically be a consequence of bug 922065 with a -3:00 TZ
> offset.
>
>
> > In any case, the most important concept to implement is the fact that
> dates
> > are timezone independant.
>
> This is already the case, at least after rev. 2067.
>
> --
> You received this bug notification because you are a member of OpenERP
> Framework Experts, which is subscribed to the bug report.
> https:/
>
> 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(
> }
> 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,
> }
>
> 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:/
>
> _______
> Mailing list: https:/
> Post to : <email address hidden>
> Unsubscribe : https:/
> More help : https:/
>
--
Gustavo Adrian Marino
Mobile: +54 911 5498 2515
Email: <email address hidden>
Skype: gustavo.