[Zope-dev] Re: Options replacing DateTime with datetime!?

[Philipp von Weitershausen]

Dieter Maurer wrote:
> Andreas Jung wrote at 2007-8-26 20:31 +0200:
>> ...
>> Conversion between both is pretty much trivial. However I have no idea
>> how this would solve the DateTime problem. So what are our DateTime 
>> problems?
>>
>> - an insane constructor with a parser trying to parse almost every
>>   date format in the world (with lots of guessing and dealing
>>   with ambiguousness)
> 
> Which you cannot get rid of -- for backward compatibility.
> 
>> - an insane timezone handling
> 
> Timezones *are* incredibly difficult. It is not "DateTimes" fault (although
> there are some bugs, almost surely easily fixable).
> 
>> - DateTime is doing way too much
> 
> Which you cannot get rid of -- for backward compatibility.

I agree with Dieter.

I acknowledge Andreas's heroic efforts trying to create a bridge between 
the two, but I do wonder if it's worth it. As Dieter said, we can't get 
rid of the cruft for BBB reasons (not only to support old code but old 
pickles as well!). The only thing we can gain here is a fix for those 
esoteric timezones bugs. That alone doesn't seem worth a risky operation 
like that.


In my personal opinion, we should

* use datetime for all the new stuff that we write,

* provide a convenient way to convert DateTime objects into datetime,

* create alternate APIs for all the APIs that work with DateTime objects 
(e.g. create a version of bobobase_modification_time that returns a 
datetime, same with the CMF DublinCore interface, etc.)

* let DateTime rot forever


Alexander Limi wrote:
> Dealing with the existing DateTime implementation has been pain since
> I started with Zope 2.0.1. I'd be willing to suffer some cleanup and
> compatibility work if it was fixed once and for all, as would anyone
> doing anything non-US-centric with dates, I imagine.

A 'cleaner', much better working version (datetime) and time zone 
support (pytz) have been around for ever since Python 2.3 was released 
and supported by Zope 2 several years (!) ago. It was everybody's choice 
NOT to use it so far.

As Andreas has pointed out, converting existing DateTime objects to 
datetime objects is trivial. In fact, what I've outline above isn't much 
work (far less than what Andreas would have to do, I would assume) and 
could've done a long time ago already. Given that you would "be willing 
to suffer some ... compatibility work" (meaning, adjusting to new APIs 
that return datetime instead of DateTime objects or adjusting your code 
to convert DateTimes to datetimes), this sounds like solution that you' 
should be happy with, too.



-- 
http://worldcookery.com -- Professional Zope documentation and training