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

Reported by Olivier Dony (OpenERP) on 2012-02-02
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenERP Server
Medium
OpenERP's Framework R&D

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?

Ferdinand (office-chricar) wrote :

what about optionally (1) displaying the time zone next to the date/time ?

(1) obviously it depends on the "context" in which the date / time is displayed

* a calendar entry must always be in users time zone
* a invoice date must always be in the time zone where it has been issued - if different from the users time zone the time zone should be displayed / printed to avoid misunderstandings.

I hate to spam mailing-lists by subscribing them to bug notifications, but I think this is an important issue that "OpenERP Framework Experts" should be aware of (this issue exists in any piece of software, actually, not just OpenERP)
Thank you for reading the bug description, all feedback welcome.

BTW I forgot to mention that option 2 from the bug description also matches the current behavior for date fields that are filled in by the user rather than by the system: the date is recorded relative to the user's timezone and will not be converted when displayed to users in a different timezone. So doing the same for default dates suggested by the system would be consistent.

On 02/02/2012 12:01 PM, Ferdinand @ Camptocamp wrote:
> * a calendar entry must always be in users time zone

Sure, and because calendar entries rely on datetime rather than pure
date values, it is automatically the case already, no change needed.

> * a invoice date must always be in the time zone where it has been
> issued - if different from the users time zone the time zone should
> be displayed / printed to avoid misunderstandings.

Based on your comment, it seems you're in favor of option 2 from the bug
description. Thanks for the feedback.
In the context of option 2, showing the "timezone of the document"
somewhere next to the "frozen" date fields (such as an invoice's date)
would indeed be useful. However storing that information either requires
some rather drastic API changes (such as an entirely new kind of date
storage format), or manual customizations of all the relevant documents.
BTW, we should keep in mind that this problem has always been present in
the past for geographically distributed teams. We can reasonably expect
team members to be quite aware of their timezone difference (they're
working different business hours!), and exert some caution when looking
at documents created by colleagues working in a different world region.
Still, that would be a nice-to-have feature, and a good suggestion for
the future, albeit probably out of scope for 6.1.

Download full text (5.4 KiB)

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?

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!
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

El 2 de febrero de 2012 09:08, Launchpad Bug Tracker <
<email address hidden>> escribió:

> You have been subscribed to a public bug by Olivier Dony (OpenERP)
> (odo-openerp):
>
> 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 lo...

Read more...

Download full text (4.8 KiB)

Hello Olivier,

Not 100% sure, but I tend to favor option 2) as well to avoid changing to
many things (imagine you would have to refactor lot's of parsing code,
lot's of comparison statements with option 1). And option 2 isn't shocking
me at this point.

Thank you for all this serious work, this is very much appreciated by us
and our customers.

On Thu, Feb 2, 2012 at 10:08 AM, Launchpad Bug Tracker <
<email address hidden>> wrote:

> You have been subscribed to a public bug by Olivier Dony (OpenERP)
> (odo-openerp):
>
> 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 provi...

Read more...

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!

Download full text (8.3 KiB)

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, ...

Read more...

Graeme Gellatly (gdgellatly) wrote :

Many months ago I reported that we should convert time.strftime defaults to use fields.date.today static method. At the time it was to stop the case of people not using lambda in defaults dict. Changing this method now and converting defaults is an answer that will work.

It will of course not adjust for timezones.

The other way is basically the same and create a wrapper class for time library, which takes an optional second argument. Although logically I'd stick this in fields.date as well.

One bonus of this approach is that in many many addons the time import purely exists to serve a defaults field.

tags: added: timezone

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.

On 02/02/2012 06:51 PM, Graeme Gellatly wrote:
> Many months ago I reported that we should convert time.strftime defaults
> to use fields.date.today static method. At the time it was to stop the
> case of people not using lambda in defaults dict. Changing this method
> now and converting defaults is an answer that will work.

Sure, this also helps to avoid such typical mistakes.

> It will of course not adjust for timezones.

Yes, not adjusting for TZ upon user display is not only inevitable but
actually a desirable property, for example for the reference date of an
invoice document. At least that's what I take from this bug thread so far.

> The other way is basically the same and create a wrapper class for time
> library, which takes an optional second argument. Although logically
> I'd stick this in fields.date as well.

Good point, that would mean something like this:

_columns = {
    'order_date': fields.date('Order Date')
}
_defaults = {
    'order_date': fields.date.user_today
}

Any better naming suggestion for the `user_today` function?

> One bonus of this approach is that in many many addons the time import
> purely exists to serve a defaults field.

True

Download full text (6.2 KiB)

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://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, n...

Read more...

Download full text (5.9 KiB)

Well fields.date.today would save me some editing but fields. Date.client_today or local_today. Only problem with user is that such a function could be quite useful server side as well like in scheduler type computation

Sent from my iPhone

On 4/02/2012, at 0:20, "Olivier Dony \(OpenERP\)" <email address hidden> wrote:

> On 02/02/2012 06:51 PM, Graeme Gellatly wrote:
>> Many months ago I reported that we should convert time.strftime defaults
>> to use fields.date.today static method. At the time it was to stop the
>> case of people not using lambda in defaults dict. Changing this method
>> now and converting defaults is an answer that will work.
>
> Sure, this also helps to avoid such typical mistakes.
>
>
>> It will of course not adjust for timezones.
>
> Yes, not adjusting for TZ upon user display is not only inevitable but
> actually a desirable property, for example for the reference date of an
> invoice document. At least that's what I take from this bug thread so far.
>
>
>> The other way is basically the same and create a wrapper class for time
>> library, which takes an optional second argument. Although logically
>> I'd stick this in fields.date as well.
>
> Good point, that would mean something like this:
>
> _columns = {
> 'order_date': fields.date('Order Date')
> }
> _defaults = {
> 'order_date': fields.date.user_today
> }
>
> Any better naming suggestion for the `user_today` function?
>
>
>> One bonus of this approach is that in many many addons the time import
>> purely exists to serve a defaults field.
>
> True
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Server.
> 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 ...

Read more...

The new method is finally called "context_today" to clearly indicate that it will work using the session context.
It was added in server trunk at revision [1] and the main places in addons that should use it were updated at revision [2].

This also leaves an easy path for fixing related minor cases in the future.

Using it as a _defaults initializer is very easy:

 _ defaults = {
    'date_field': fields.date.context_today,
 }

No need to import time or use a lambda anymore...

Thanks everyone who provided feedback!

PS: no similar method fields.datetime.context_now was created because datetime values behave as expected when computed in server time, so it is better to use the existing UTC-based fields.datetime.now (also usable for _defaults)

[1] server trunk r.4050 rev-id: <email address hidden>
[2] addons trunk r.6565 rev-id: <email address hidden>

Changed in openobject-server:
status: Confirmed → Fix Released

I think there is one more addon module that needs to have this love: hr_timesheet_sheet.py. I'm looking through it, but I think it's going to be a little more difficult to correct for those outside of UTC +0. I posted a bug (https://bugs.launchpad.net/openerp-web/+bug/943091), that details some of the issues. The main problem has to do with attendance displayed for the local date, not UTC date.

hello i see there is a good job for trunk but i get the follow problem in 6.1:

If system works with with UTC, here in Ecuador with GMT -5 when try to use:

>>> from time import strftime
>>> strftime('%H:%M:%S')

gets +5 hours, i find out this and system force python to use UTC, timezone in Web UI is set to America/Guayaquil but is not ok in server.

Please set a highly priority to this, we are trying to make a simple computation with datetime field (field has a correct value) and we are stopped.

Regards,

Additional, this bug is set to Fix released but branches merged are in trunk.

I am not consider a solution add a simple method to return a value and says is fixed.

Many developers use time library, far as i know python is not deprecating time library.

This is totally locking for us.

Regards,

On 08/21/2012 06:04 PM, Cristian Salamea (Gnuthink) wrote:
> If system works with with UTC, here in Ecuador with GMT -5 when try to
> use:
>
>>>> from time import strftime
>>>> strftime('%H:%M:%S')

This will give you the current UTC time, and it is by design in 6.1.
There is one golden rule for datetime fields in 6.1 addons code:
 "ALWAYS work in UTC - compute in UTC - save in UTC"
The UTC values will be properly converted to local time when the result is
diplayed in a client-side form.

> gets +5 hours, i find out this and system force python to use UTC,
> timezone in Web UI is set to America/Guayaquil but is not ok in server.

If for some reason you *really* want to use the local time (it is probably a
mistake!) you can use fields.datetime.context_timestamp. Have a look at the
docstring.

PS: You're posting this on a bug that talks about pure date fields, but your
sample code uses the time only... this is pretty weird. For *date* fields
fields the logic is completely different, I'm afraid you're mixing different
issues.
This is complicated stuff, you should read very carefully the explanations on
this bug and on related bugs to make sure you understand how it works for the
various types of fields.

Looks this results in runtime OpenERP debugging with pdb http://dpaste.org/CwcOx/.
localtime() and gmtime() are the same, how openerp solve this in runtime ?

Regards,

On 08/21/2012 07:28 PM, Cristian Salamea (Gnuthink) wrote:
> Looks this results in runtime OpenERP debugging with pdb http://dpaste.org/CwcOx/.
> localtime() and gmtime() are the same, how openerp solve this in runtime ?

This is by design, as explained. OpenERP forces the standard Python modules to
act as if the local timezone was UTC. This is the key to implementing proper
datetime computations in server-side in 6.1.

BTW this is not the right question to ask, the right question would be: why do
you want to have a non-UTC time on server-side?! You should never need it if
you respect the rule.

PS: please don't use bug comments for help when you don't understand something,
Launchpad answers or the mailing-lists are better suited

Yes and i am agree to force this but stored values in timestamp w/o in Postgres are different with user see.

What if i need to dump data directly from DB (common task in DBA) store value are different what users see.

Regards,

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers