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.
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 = { date.user_ today
'order_date': fields.date('Order Date')
}
_defaults = {
'order_date': fields.
}
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