[egenix-users] Possible bug: DateTime.localtime() crash wit
h the year 2065 (Wi n32 platform)
lalleman at mfps.com
Tue Apr 27 09:45:12 CEST 2004
I'll be sure to give egenix-mx-base 2.1 a try when it becomes available. I
would much rather deal with an exception or even the wrong value, rather
than an interpreter crash.
From: M.-A. Lemburg [mailto:mal at egenix.com]
Sent: Tuesday, April 27, 2004 2:54 AM
To: Alleman, Lowell
Cc: 'egenix-users at lists.egenix.com'
Subject: Re: [egenix-users] Possible bug: DateTime.localtime() crash
with the year 2065 (Wi n32 platform)
Alleman, Lowell wrote:
> Hello all,
> I recently came across a problem with the mx.DateTime module. I
> my problem down to the following:
> PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
>>>>dt = mx.DateTime.DateTime(2065)
> <--- Interpreter crashes here --->
> The crash manager in Windows indicates that the problem occurred in
> mxdatetime.pyd. I have tried this on three different machines.
> 1. Windows XP, Python 2.3.3, with PythonWin build 200, and mx.DateTime
> version 2.0.3.
> 2. Windows 2000, Active Python 2.3.2 build 232, and mx.DateTime 2.0.3
> 3. SuSE Linux 9.0, "Python 2.3+", and mx.DateTime 2.0.3. (I'm not
> sure what "Python 2.3+" means. The rpm calls itself "python-2.3-52")
> The interrupter crashed on both of the Windows machines. My Linux machine
> did not crash, it simply said that the
> mx.DateTime.DateTime(2065).localtime() was really 1901, which is clearly
> incorrect, but better than crashing, I guess. It would appear that
> localtime() is an OS-dependant thing.
The problem is related to how the C lib handles these dates.
localtime() uses the C lib's time functions to do the
calculations and, depending on their implementation (e.g.
using 32-bits to represent seconds since the epoch), these
can result is wrong results for dates outside the range
1970 - 2038.
FWIW, the mxDateTime version in the yet unreleased egenix-mx-base 2.1
does some extra tests to catch these situations - provided that the
C lib function itself doesn't crash.
> I'm not sure if this is the correct place to ask questions about bugs. I
> know that there is a commercial support area, but I not currently a
> and mx.DateTime is freely available. (FYI: I am considering the purchase
> of the mxODBC module). Anyways, I can hack around this bug myself for the
> time being, but I figured that this may be something that the authors
> like to fix, assuming that what I found is really a bug. A interpreter
> crash is never fun.
Professional Python Services directly from the Source (#1, Apr 27 2004)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
EuroPython 2004, Göteborg, Sweden 40 days left
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
More information about the egenix-users