[ python-Bugs-874042 ] wrong answers from ctime

[SourceForge.net]

Bugs item #874042, was opened at 2004-01-09 20:57
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874042&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong answers from ctime

Initial Comment:
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'



----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2004-06-19 04:42

Message:
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.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-19 01:43

Message:
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"?

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 18:11

Message:
Logged In: YES 
user_id=1057404

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

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-06-05 18:08

Message:
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");
###

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-01-09 21:49

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-01-09 21:22

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874042&group_id=5470