[Python-Dev] Boundary checks on arguments to time.strftime()

[Guido van Rossum]

> [Brett]
> > Bug #897625 (http://python.org/sf/897625) deals with giving
> > time.strftime() date information that is outside of proper bounds
> (e.g.,
> > using a negative number for the day of the week).  This can lead to a
> > crash since it seems some strftime implementations just index into an
> > array for values for text and thus a negative value can lead to bad
> > things happening.
> > 
> > I would like to raise a ValueError if the argument is out of range.
> > Problem is that this will break code. 
> 
[RH]
That is the right way to go.  The docs have long specified the proper
> range of input values.  If someone has created working code outside
> those bounds, raising an exception may be their only clue that their
> code is non-portable (best case) or simply buggy (worst case).

Agreed.  How could an out-of-range causes crashes in the
implementation *and* be a required feature?

> > I could just force all negative
> > values to all values outside the proper bounds to a reasonable value,
> > but that seems to go against the path of least surprise.  That is
> > question 1.
> 
> -1.  That is slower and more likely to mask genuine coding bugs.  Also,
> it introduces new behavior that would need to be supported in
> perpetuity.

Agreed.

> > Question 2 is what to really check.  This really is only a concern for
> > month and day of the week since everything else is just a number and
> > doesn't have some name representation.  I could check all 9 values,
> > though, or just these two.
> 
> The month and day of week are the most important since they have word
> name equivalents that are found by indexing into an array of pointers.
> But, if you're feeling bold, go ahead and check all of the ranges
> specified in the docs.   That will make it more likely that programmer
> errors and non-portable wrapping tricks are detected early.

To be consistent you should check all values.

You could go oveboard and check for things like February 29, but I
recommend against this.  After all strftime() only does formatting.

> > Question 3 is whether to extend this to time.asctime() .  I have
> > talked to Tim about this and his thoughts are to just deal with
> > time.strftime() and leave everything else alone.  That's fine with
> > me, but there is the same possibility of having problems with
> > asctime().  But then again, checking value for asctime() would
> > potentially break even more code.

Why?  The question is, do we need to check to protect the
implementation?  Then I'd say we have no choice.  Otherwise, the
question is, should we let bad input cause bad output (the GIGO
principle) or should we try to flag it?  Which is better for the
average application?  Given that asctime() is likely used for printing
messages, causing new exceptions in code that "worked" before is going
to get complaints from users who deploy buggy programs and get
embarrassed by the new exception.  Has happened before.

> I would leave time.asctime() alone.  Its argument is typically one
> returned by another time function.  So, it is less susceptible than
> strftime() where the arguments are constructed piecemeal.

That I don't know.  More likely, asctime() is simply not used as much,
because its (fixed) output formats has few virtues except being an
ancient Unix standard, and in today's internet world that's not enough.

--Guido van Rossum (home page: http://www.python.org/~guido/)