+-------[ Philipp von Weitershausen ]----------------------
| 2. If we find it's possible, we rid the current DateTime implementation
| and recreate the DateTime class by subclassing datetime.datetime. For
| backwards compatability, we make sure that old pickles can be revived
| and that the old DateTime API is supported for two more Zope releases.
| 3. After two releases we get rid of the old DateTime API and will
| provide a script to migrate old DateTime pickles to datetime.datetime
| pickles in the ZODB.
-1 for any scheme that deliberately breaks currently working code / installs.
-1 for any scheme that involves diddling the ZODB to 'fix' pickles, because
you just know you're going to corrupt someone's ZODB, and that's just
noone's idea of fun.
Didn't see any mention of fixing ZClasses (not sure if that's an issue).
I'm the first in line of the people wanting Zope DateTime to die. However, you
need to leave it there. Fix Zope to internally use something different, and
provide a new implementation that 'sensible' people can use going forwards.
Motivated developers can then move to the new API. Grumbling users can
motivate their developers to migrate their code to the new API (or submit
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -