Philipp von Weitershausen wrote:
Chris suggests. Why does it need to be persistent?
See the use case I sketched out in my other reply...
1. Create some extensive tests about how DateTime currently works. I'm currently working on this to see whether any further procedure makes sense.
yay!
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.
-1 Too complicated. I prefer the deprecate, provide migration utility, then remove method...
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.
...yes, this. Just skip step 2 ;-)
By the way, I only skimmed over this thread, but I haven't actually found anywhere explained what Hermann's problem with strftime was and a detailed suggestion on how his "rewrite" would take place... Maybe it'd be a good idea to adopt the proposal process we have for Zope 3.
As I said elsewhere, I'd love to have one datetime and timezone story for both Zope 2 and Zope 3, and I think Zope 3 has better processes for making that happen ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk