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

[Andreas Jung]

--On 25. August 2007 12:33:41 -0400 Tres Seaver <tseaver at palladion.com> 
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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 :-)

>
> 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.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20070825/5aa2f5c0/attachment.bin