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

[Raymond Hettinger]

[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. 

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


> 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.

> 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.


> 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.

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.


Raymond Hettinger