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