-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Santi Camps wrote:
En/na Andreas Jung ha escrit:
--On Donnerstag, 12. Mai 2005 18:34 Uhr +0200 Santi Camps <scamps@earcon.com> wrote:
En/na Andreas Jung ha escrit:
--On Mittwoch, 11. Mai 2005 16:08 Uhr +0200 Santi Camps <scamps@earcon.com> wrote:
> d = DateTime('2045/30/01') > d.strftime('%d/%m/%Y') DateTime.DateTime.TimeError: The time 2369343600.000000 is beyond the range of this Python implementation
I've read that the reason was a validation to avoid int overflows. I think this could be fixed using datetime module (new in python 2.3) instead of old time.localtime
After some testing: datetime has the same problems and it is unlikely that we can solve this problem in Zope as long as the underlying implementation in the libc sux (or better is constrained on 32 bit systems).
-aj
At least is possible to fix the problem in strftime method. I attach a patch that works for me. Hope this can be commited.
If you provide some unittests then this would make a perfect patch :-)
-aj
I'm trying to do it, but one test fails. I can't understand this behaviour:
DateTime('2004/01/01')._tz 'GMT+1' DateTime('2000/06/16')._tz 'GMT+2'
Why different time zones are assigned ? I was thinking that the machine time zone was always used when not specified
The local machine's default timezone, including applicable Daylight Savings / Summer Time rules, is used if no explicit time zone is given. Tres. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCg7aV+gerLs4ltQ4RAofSAJ9XDz+ZcU2BGUQYox34+lS+MgrbhACgobeu H5PtcCOdS7NF9A1vspN2iMY= =IYRQ -----END PGP SIGNATURE-----