[Python-Dev] Checking input range in time.asctime and time.ctime

[Guido van Rossum]

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.belopolsky at 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 at 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)