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

[Philipp von Weitershausen]

Tres Seaver wrote:
>>> Andreas Jung wrote:
>>>> Hi,
>>>>
>>>> perhaps the sun burned too long on my brain today but I investigated
>>>> some  options for replacing DateTime with Python's datetime module. Zope
>>>> 3 uses datetime and we all know that the DateTime implementation sucks.
>>>> Especially  the timezone implementation has a bunch of problems (count
>>>> the bugtracker  issues related to timezone errors).
>>>>
>>>> Constraints:
>>>> We can not get rid of the DateTime class and its API for backward
>>>> compatibility reasons.
>>>>
>>>> Idea:
>>>> The DateTime class remains in place and uses an instance attribute to
>>>> represent the original value of a DateTime object as instance of
>>>> datetime. Calls to the old DateTime API are proxied to corresponding
>>>> calls of the datetime API (or emulated)
>>>>
>>>> Efforts so far:
>>>> I have some quick-and-dirty implementation that can construct the
>>>> datetime instance directly within the DateTime constructor and when
>>>> loading an object from the ZODB (using a custom __setstate__()
>>>> implementation...could be used for an on-the-fly migration). This seems
>>>> to  work properly. For timezone related issues I am using pytz. However
>>>> there  is a problem with using pytz: the timezone names supported by
>>>> pytz are  sometimes different from the standard one. E.g. 'GMT+0400' is
>>>> represented  in pytz as '/Etc/GMT+0400'...however that seems to be
>>>> solvable.
>>>>
>>>> Before digging deeper I would like to hear some opinions if this seems a
>>>> reasonable approach? Unlikely that we can achieve 100% backward
>>>> compatibility but possibly 99%....thoughts...comments?
>>> I'm generally in favor of this, but only if we eggify the *current*
>>> DateTime implementation such that people who rely on the incompatible
>>> behavior can specify the older version.
>> Jup, but eggification would likely be the last (and possibly the most easy)
>> step :-)
> 
> Eggifying the current package shouldn't be hard (it has no dependencies
> except for zope.interface.  In fact, it looks as though Philipp has done
> it already:

Yup. Behold:

* http://svn.zope.org/DateTime/trunk/

   It's currently pulling in the source through an external, but I see no
   reason why it can't be moved in its own project area. Stuff like
   DateTime is going to have lots of fixes for already running
   applications (like timezone fixes, etc.), so having it keep its own
   release cycle makes sense to me, especially when it's now being
   evolved towards datetime. The rest of the eggs I created (Acquisition,
   ExtensionClass, etc.) are mostly independend of the rest of Zope 2 as
   well and could gain their own projects just as well. Not a full-scale
   explosion, but just some factoring out...

* http://download.zope.org/distribution/DateTime-2.11.0a1.dev-r76287.tar.gz
 
http://download.zope.org/distribution/DateTime-2.11.0a1.dev_r76287-py2.4.egg

   A ready to go egg of DateTime, completely independent from Zope 2
   (only dependencies are zope.interface and zope.testing I believe).



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