[Python-Dev] Checking input range in time.asctime and time.ctime
alexander.belopolsky at gmail.com
Tue Jan 4 01:06:04 CET 2011
There are several reports of bugs caused by the fact that the behavior
of C functions asctime and ctime is undefined when they are asked to
format time for more than 4-digit years:
http://bugs.python.org/issue10563 (superseded by #8013)
I have a patch ready at issue 8013 that adds a check for large values
and causes time.asctime and time.ctime raise ValueError instead of
producing system-dependent results or in some cases crashing or
corrupting the python process.
There is little dispute that python should not crash on invalid input,
but I would like to ask for a second opinion on whether it would be
better to produce some distinct 24-character string, say 'Mon Jan 1
00:00:00 *999', instead of raising an exception.
Note that on some Windows systems, the current behavior is to produce
'%c999' % (year // 1000 + ord('0')) for at least some large values of
year. Linux asctime produces strings that are longer than 26
characters, but I don't think we should support this behavior because
POSIX defines asctime() result as a 26 character string and Python
manual defines time.asctime() result as a 24 character string.
Producing longer timestamps is likely to break as many applications as
accepting large years will fix. OSX asctime returns a NULL pointer for
My position is that raising an error is the right solution. This is
consistent with year range supported by datetime.
Another small issue that I would like to raise here is issue6608 patch
resulting in time.asctime() accepting 0 as a valid entry at any
position of the timetuple. This is consistent with the behavior of
time.strftime(), but was overlooked when issue6608 was reviewed. I
find the case for accepting say 0 month or 0 day in time.asctime()
weaker than that for time.strftime() where month or day values may be
More information about the Python-Dev