For any time value less than -2**31, ctime returns the
same result, 'Fri Dec 13 12:45:52 1901'.  It should
either compute a correct value (preferable) or raise
ValueError.  It should not return the wrong answer.


>>> from time import *
>>> ctime(-2**31)
'Fri Dec 13 12:45:52 1901'
>>> ctime(-2**34)
'Fri Dec 13 12:45:52 1901'
>>> ctime(-1e30)
'Fri Dec 13 12:45:52 1901'

Logged In: YES 
user_id=31435

Please identify the Python version, OS and C runtime you're 
using.  Here on Windows 2.3.3,

>>> import time
>>> time.ctime(-2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: unconvertible time
>>>

The C standard doesn't define the range of convertible values 
for ctime().  Python raises ValueError if and only if the 
platform ctime() returns a NULL pointer.

Logged In: YES 
user_id=72053

Python 2.2.2, Red Hat GNU/Linux version 9, not sure what C
runtime, whatever comes with Red Hat 9.

If the value is coming from the C library's ctime function,
then at minimum Python should check that the arg converts to
a valid int32.   It sounds like it's converting large
negative values (like -1e30) to -sys.maxint.  I see that
ctime(sys.maxint+1) is also being converted to a large
negative date.  Since python's ctime (and presumably related
functions) accept long and float arguments, they need to be
range checked.

Logged In: NO 

I wish SF would let me upload patches. The below throws a
ValueError when ctime is supplied with a negative value or a
value over sys.maxint.

###
diff -u -r2.140 timemodule.c
--- timemodule.c        2 Mar 2004 04:38:10 -0000       2.140
+++ timemodule.c        5 Jun 2004 17:11:20 -0000
@@ -482,6 +482,10 @@
                        return NULL;
                tt = (time_t)dt;
        }
+       if (tt > INT_MAX || tt < 0) {
+               PyErr_SetString(PyExc_ValueError,
"unconvertible time");
+               return NULL;
+       }
        p = ctime(&tt);
        if (p == NULL) {
                PyErr_SetString(PyExc_ValueError,
"unconvertible time");
###

Logged In: YES 
user_id=1057404

The below is from me (insomnike) if there's any query. Like
SF less and less.

Logged In: YES 
user_id=357491

I get the "problem" under 2.4 CVS on OS X.  But as Tim said, the ISO C 
standard just says that it should accept time_t which can be *any* 
arithmetic type.  I say don't bother fixing this since you shouldn't be 
passing in random values to ctime as it is.  Plus ctime is not the best 
way to do string formatting of dates.

What do you think, Tim?  Think okay to just close this sucker as "won't 
fix"?

Logged In: YES 
user_id=72053

I think this needs to be fixed and not just closed.  Ctime
in a C library might be able to accept any numeric type as a
time_t, but no matter what type that turns out to be, I
don't think ctime is allowed to give a totally wrong answer.
 The issue here is Python numeric types don't necessarily
map onto C numeric types.  I think it's ok to raise an
exception if a Python integer doesn't correctly map onto a
valid time_t, but the current behavior is to map
incorrectly.  That can cause all kinds of silent bugs in a
program.

Logged In: YES 
user_id=31435

Sorry, I can't make more time for this.  Attached is a patch 
that's the best I can do without #ifdef'ing the snot out of 
every platform on Earth.  As the comments explain, it's not 
bulletproof (and probably can't be).  It introduces a 
_PyTime_DoubleToTimet() function that attempts to 
detect "unreasonable" information loss, and fiddles ctime(), 
localtime() and gmtime() to use it.  It should really be made 
extern (added to Python's internal C API & declared in a 
header file), and little bits of datetimemodule.c fiddled to use 
it too.

insomnike, while C89 was clear as mud on this point, C99 is 
clear that there's nothing wrong with a negative time_t 
value, and *most* platforms accept them (back to about 
1900).  Nothing says a time_t can't be bigger than INT_MAX 
either, and, indeed, platforms that use ints to store time_t 
will be forced to switch to fatter types before Unix hits its 
own version of "the Y2K bug" in a few decades (the # of 
seconds since 1970 is already over a billion; signed 32-bit ints 
will be too small in another 30+ years).

Logged In: YES 
user_id=31435

I should note that datetime.ctime() works reliably and 
portably for all years in 1 thru 9999 (it doesn't use the 
platform C library, so is sane).

OTOH, the assorted datetime constructors that build from a 
POSIX timestamp have the same kinds of endcase portability 
woes as the time module functions working from timestamps.

Logged In: YES 
user_id=357491

OK, code looked good to me, so I checked it in as rev. 2.141 of 
timemodule.c on HEAD (not patching to 2.3 since not critical bugfix).  
Didn't add it to the C API (and thus did not change 
datetime) for lack of time.  Filed bug #975996 to make sure it eventually 
gets done.

Logged In: YES 
user_id=31435

Changed resolution to Fixed.