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.

-- -- Professional Zope documentation and training
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to