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/issue8013 http://bugs.python.org/issue6608 (closed) 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 large years. 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 ignored. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
