[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/)