Fix bug #1520914. Starting in 2.4, time.strftime() began to check the bounds
of values in the time tuple passed in. Unfortunately people came to rely on
undocumented behaviour of setting unneeded values to 0, regardless of if it was
within the valid range. Now those values force the value internally to the
minimum value when 0 is passed in.
diff --git a/Modules/timemodule.c b/Modules/timemodule.c
index 402e349..eb279fc9 100644
--- a/Modules/timemodule.c
+++ b/Modules/timemodule.c
@@ -406,13 +406,35 @@
indexing blindly into some array for a textual representation
by some bad index (fixes bug #897625).
- No check for year since handled in gettmarg().
+ Also support values of zero from Python code for arguments in which
+ that is out of range by forcing that value to the lowest value that
+ is valid (fixed bug #XXX).
+
+ Valid ranges based on what is allowed in struct tm:
+
+ - tm_year: [0, max(int)] (1)
+ - tm_mon: [0, 11] (2)
+ - tm_mday: [1, 31]
+ - tm_hour: [0, 23]
+ - tm_min: [0, 59]
+ - tm_sec: [0, 60]
+ - tm_wday: [0, 6] (1)
+ - tm_yday: [0, 365] (2)
+ - tm_isdst: [-max(int), max(int)]
+
+ (1) gettmarg() handles bounds-checking.
+ (2) Python's acceptable range is one greater than the range in C,
+ thus need to check against automatic decrement by gettmarg().
*/
- if (buf.tm_mon < 0 || buf.tm_mon > 11) {
+ if (buf.tm_mon == -1)
+ buf.tm_mon = 0;
+ else if (buf.tm_mon < 0 || buf.tm_mon > 11) {
PyErr_SetString(PyExc_ValueError, "month out of range");
return NULL;
}
- if (buf.tm_mday < 1 || buf.tm_mday > 31) {
+ if (buf.tm_mday == 0)
+ buf.tm_mday = 1;
+ else if (buf.tm_mday < 0 || buf.tm_mday > 31) {
PyErr_SetString(PyExc_ValueError, "day of month out of range");
return NULL;
}
@@ -434,7 +456,9 @@
PyErr_SetString(PyExc_ValueError, "day of week out of range");
return NULL;
}
- if (buf.tm_yday < 0 || buf.tm_yday > 365) {
+ if (buf.tm_yday == -1)
+ buf.tm_yday = 0;
+ else if (buf.tm_yday < 0 || buf.tm_yday > 365) {
PyErr_SetString(PyExc_ValueError, "day of year out of range");
return NULL;
}