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) < > 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, 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. > > 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 > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-framework > Post to :