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