| 2009-03-04 14:56:25 |
kevingill |
description |
I recently upgraded a Zope instance from 2.9.3 to 2.11.1.
Some odd behaviour occurs when calling the strftime method on DateTime instances created in 2.9.3 or earlier:
The date that is formatted is always the current date and time, not that stored in the DateTime object.
For me, this has been on Date properties and saving the properties via the manage_propertiesForm seems to fix the issue. But, there's obviously a bug lurking here which could be much more serious for other people... |
I recently upgraded a Zope instance from 2.9.3 to 2.11.1.
Some odd behaviour occurs when calling the strftime method on DateTime instances created in 2.9.3 or earlier:
The date that is formatted is always the current date and time, not that stored in the DateTime object.
For me, this has been on Date properties and saving the properties via the manage_propertiesForm seems to fix the issue. But, there's obviously a bug lurking here which could be much more serious for other people...
=============
This problem is caused by the changes in DateTime between Zope 2.10 and 2.11. The DateTime object now calculates and stores a date in micro-seconds and stores that on the DateTime object using an attribute _micros.
The ZODB uses the pickler to load DateTime objects.
First the pickler creates a new DateTime object using a single parameter None, which creates a new DateTime and initialises it to the currrent time. The DateTime dictionary is constructed, including the _micros attribute.
The the pickler loads the object dictionary using the values stored in the ZODB. The stored values do not include a _micros attribute, so the _micros attribute is not overridden (thus it includes the current time).
If you retrieve the DateTime objects directly or use the str() method, the correct values are returned. However, if you use a method which uses the underlying _micros value such as comparison functions or asdatetime(), you get an incorrect value.
|
|
