[Zope] DateTime mess

[Chris Withers]

> A piece of code calls bobobase_modification_time() which currently
> returns a DateTime; after that the piece of code calls some
> DateTime-specific methods on the returned object. Now in Zope 2.12 we
> make bobobase_modification_time() return a datetime.datetime and
> subsequently the piece of code would fail. There are a lot of pieces of
> code like this in third party products...

Good point, I don't see a nice way around this though :-S
Your frankendatetime is one possibility, but for me it feels just as 
nasty as the scenario you describe above :-S

> We could deprecate DateTime now to warn people about that. But then
> their product would only either work with Zope <2.12 or with Zope >2.12
> (depending on whether it still expects the DateTime API or the
> datetime.datetime API); it would not with both versions. That's a harsh
> upgrade plan and it would probably take ages before people would adopt
> Zope 2.12.

Yup...

> With a frankendatetime in Zope 2.10, however, they could still call
> DateTime-specific methods on the return value of
> bobobase_modification_time(). They'd get deprecation warnings telling
> them to use the datetime.datetime API instead. That would work
> instantly, not only in Zope 2.12. That way they could smoothly upgrade
> their products.

OK, I'm convinced, _if_ you can make it work ;-)

> By the way, I've come to think that touching the current DateTime
> implementation wouldn't be a good idea, mostly because of the old
> pickles issue. 

My thoughts exactly.


> The frankendatetime should be a separate class that
> subclasses datetime.datetime, provides old-style DateTime compatability
> and has datetime.datetime-compatible pickles.

sounds good to me :-)

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk