Lennart Regebro wrote:
>>Datetimes are dull values, they should just pickle nicely.
> They do.
Yes, that's my point. That's why we don't need added persistency.
> A module with extra utilities + timezone support would be nice.
pytz provides some extensive timezone support. Not sure what the extra
utilities are, but I don't have a lot of complicated datetime use cases
so I could be missing stuff here.
>>1. Create some extensive tests about how DateTime currently works. I'm
>>currently working on this to see whether any further procedure makes sense.
> I'm not worried about how it works now. DateTime is buggy and it's
> behaviour has undergone several subtle changes, sometimes for the
> worse, without much screaming. :-)
Well, I'm not so worried about the past but about the future. I'm
currently diving into the matter by writing doctests. If we find that
DateTime and datetime.datetime are semantically incompatible, we'll have
to think up a different strategy. We'll see :).
>>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.
> Yeah, it's that pickling revival that worries me. It's non-trivial.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -