Given the rule garbage in -> garbage out, I'd do the most useful thing, which would be to produce a longer output string (and update the docs). This would match the behavior of e.g. '%04d' % y when y > 9999. If that means the platform libc asctime/ctime can't be used, too bad.
--Guido On Mon, Jan 3, 2011 at 4:06 PM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
