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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
