-----BEGIN PGP SIGNED MESSAGE-----
Andreas Jung wrote:
> --On 25. August 2007 12:33:41 -0400 Tres Seaver <[EMAIL PROTECTED]>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Andreas Jung wrote:
>>> 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).
>>> We can not get rid of the DateTime class and its API for backward
>>> compatibility reasons.
>>> 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
>>> 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
So releasing an egg from there should be straightforward.
>> Note that a lot of the code in DateTime is the constructor DWIM, which
>> datetime completely lacks (in fact, the lack of a string-to-datetime
>> parser in the standard library is a major pain). That DWIM *must*
>> remain in place, even in the new version, as too much application code
>> depends on it.
> DWIM? The conversion to datetime happens in my place after calling
> _parse_args() which is a big pita code...if you mean this...yes, I would
> _never_ touch it.
The parsing is what I meant, along with the DWIM related to number of
arguments passed to the constructor.
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -