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

[Tres Seaver]

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

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.


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

iD8DBQFG0Fnl+gerLs4ltQ4RAuW5AJ9JwY+jKGg93WvFmYT1bNrUx+qU1wCgxlwd
OdZsF5Q59b92CLrJ3f4xXvc=
=NOea
-----END PGP SIGNATURE-----