[egenix-users] Possible bug: DateTime.localtime() crash wit h the year 2065 (Wi n32 platform)

Alleman, Lowell 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.

Thanks again,

Lowell Alleman

-----Original Message-----
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
simplified
> my problem down to the following:
> 
> 
> 
> PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
on
> win32.
> 
>>>>import mx.DateTime
>>>>dt = mx.DateTime.DateTime(2065)
>>>>dt.localtime()
> 
> 
>     <--- 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
exactly
> 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
customer
> 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
would
> like to fix, assuming that what I found is really a bug.  A interpreter
> crash is never fun.

-- 
Marc-Andre Lemburg
eGenix.com

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 mailing list