Hi all, I think its known that using strftime method of DateTime module with dates <= 1900 or >= 2038, a TimeError is raised. For instance:
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 Do you think its a good idea ? Can I provide a patch that way ? Thanks Santi Camps
On May 11, 2005, at 10:08 AM, Santi Camps wrote:
I think its known that using strftime method of DateTime module with dates <= 1900 or >= 2038, a TimeError is raised. For instance:
DateTime can handle dates with larger ranges, it just can't display them with the strftime method. DateTime's strftime method is impelemented with the standard C libraries' strftime(), and a C time_t datatype only represents dates between 1970 and 2038.
En/na Andrew Langmead ha escrit:
On May 11, 2005, at 10:08 AM, Santi Camps wrote:
I think its known that using strftime method of DateTime module with dates <= 1900 or >= 2038, a TimeError is raised. For instance:
DateTime can handle dates with larger ranges, it just can't display them with the strftime method.
DateTime's strftime method is impelemented with the standard C libraries' strftime(), and a C time_t datatype only represents dates between 1970 and 2038.
Yes, I know, but displaying them through a datetime.datetime object the display can also work fine. That's my proposal. Santi Camps
--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
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. Santi Camps
--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
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 Santi Camps
-----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-----
The local machine's default timezone, including applicable Daylight Savings / Summer Time rules, is used if no explicit time zone is given.
Tres.
Thanks very much for your answer, Tres. Now I've been able to understand what's doing and provide a patch. I've created a new Issue in the Collector and attached the patch with some unittests there: http://www.zope.org/Collectors/Zope/1780 Hope this help Santi Camps
Andreas Jung wrote at 2005-5-12 14:24 +0200:
... 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).
It would not be too difficult to reimplement "strftime" in Python -- especially with the information held in a "DateTime". Maybe an exercise for someone who needs "strftime" for dates outside the supported range? -- Dieter
participants (5)
-
Andreas Jung -
Andrew Langmead -
Dieter Maurer -
Santi Camps -
Tres Seaver