[ python-Bugs-874042 ] wrong answers from ctime
SourceForge.net
noreply at sourceforge.net
Sat Jun 19 16:54:41 EDT 2004
Bugs item #874042, was opened at 2004-01-09 12:57
Message generated for change (Comment added) made by bcannon
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: Closed
>Resolution: Accepted
Priority: 4
Submitted By: paul rubin (phr)
Assigned to: Brett Cannon (bcannon)
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: Brett Cannon (bcannon)
Date: 2004-06-19 13:54
Message:
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.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-06-19 13:18
Message:
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.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-06-18 23:32
Message:
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).
----------------------------------------------------------------------
Comment By: paul rubin (phr)
Date: 2004-06-18 21: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-18 18: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 11: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 11: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 13: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 13: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
More information about the Python-bugs-list
mailing list