There is a bug in datetime.fromtimestamp(), whereby if it is called with -1, it fails with "mktime argument out of range" when it should not (see attached test program to reproduce the problem).

The bug is that the way that mktime() signals an error code is subtle and error-prone: you need to set a sentinel in the tm's wday or yday and not only check the return value of mktime, but also check if those values have been modified; it figures: -1 is a valid value in the return domain of mktime() and is not a sufficient condition for signaling an error.

Here is the relevant excerpt from the Linux man page:


       The mktime() function converts a broken-down time structure,  expressed
       as  local  time, to calendar time representation.  The function ignores
       the specified contents of the structure members tm_wday and tm_yday and
       recomputes  them  from  the  other  information in the broken-down time
       structure.  If structure members are outside their legal interval, they
       will  be normalized (so that, e.g., 40 October is changed into 9 Novem-
       ber).  Calling mktime() also sets the  external  variable  tzname  with
       information  about the current time zone.  If the specified broken-down
       time cannot be represented as calendar time (seconds since the  epoch),
       mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
       and tm_yday members of the broken-down time structure.


This was found under Linux, I do not know if this bug also occurs on Windows or the Mac.

I attached a couple of files:

- timebug.py: reproduce the bug
- timebug.c: tests that mktime()'s behaviour is as wicked as expected
- timebug.patch: the fix to the datetime module.



P.S. I hit this bug in a graphics application while zooming in/out of a viewer rendering time-based data. Sheer luck.