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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Jung wrote:
> 
> --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 :-)

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:

  http://mail.zope.org/pipermail/checkins/2007-June/010134.html

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.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
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

iD8DBQFG0I9P+gerLs4ltQ4RAjIoAJ42UYkVxnqmjQxIVavDbE33URBoqACfad00
7hoDj7oxRy+KyhdrlxqidIA=
=QvY6
-----END PGP SIGNATURE-----