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