[Zope] DateTime mess

Philipp von Weitershausen philipp at weitershausen.de
Mon Nov 28 06:32:07 EST 2005


Chris Withers wrote:
> Andreas Jung wrote:
> 
>>
>> I agree that is should be replaced but I also mentioned that we tried
>> to achieve that already some years ago and we gave up....so talking
>> about deprecation really makes sense when someone puts a replacement
>> module on the table. I know that the DateTime module is a piece of
>> crap but crap you can live mostly with (as long as you don't need
>> timezones :-)).
> 
> 
> Okay, well, I'd advocate replacement with a zope.datetime that
> subclasses python's datetime, mixes in persistence and provides some of
> the extra helper methods.
> 
> What do people think?
> 
> cheers,
> 
> Chris
> 
> (CC'ing Phillip 'cos I saw him doing some Zope 3'ish DateTime stuff...)

Hey Chris, hey Hermann, hey others,

I've secretly being working on some evil plans to make DateTime more
understandable so that we can work out a migration strategy. In my
strong opinion, Zope should not maintain its own date/time
implementation and I don't even see the need for a zope.datetime like
Chris suggests. Why does it need to be persistent? Datetimes are dull
values, they should just pickle nicely. If someone needs more than
datetime.datetime and pytz, I would be very interested in their usecase...

Anyway, my long-term plans are roughly this:

1. Create some extensive tests about how DateTime currently works. I'm
currently working on this to see whether any further procedure makes sense.

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.

I have a proposal for this in works, but you guys made me blurt it out
prematurely :).

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.

Philipp


More information about the Zope mailing list