I give up: unless I write my own strftime by hand, datetime just can't

be trusted with years before 1900, so now we raise ValueError if a date or
datetime or datetimetz .strftime() method is called with a year before
1900.

1 files changed, 25 insertions, 0 deletions

diff --git a/Modules/datetimemodule.c b/Modules/datetimemodule.c
index 28f61bd..a9675d6 100644
--- a/Modules/datetimemodule.c
+++ b/Modules/datetimemodule.c
@@ -940,6 +940,31 @@ wrap_strftime(PyObject *object, PyObject *format, PyObject *timetuple)
 	assert(object && format && timetuple);
 	assert(PyString_Check(format));
 
+	/* Give up if the year is before 1900.
+	 * Python strftime() plays games with the year, and different
+	 * games depending on whether envar PYTHON2K is set.  This makes
+	 * years before 1900 a nightmare, even if the platform strftime
+	 * supports them (and not all do).
+	 * We could get a lot farther here by avoiding Python's strftime
+	 * wrapper and calling the C strftime() directly, but that isn't
+	 * an option in the Python implementation of this module.
+	 */
+	{
+		long year;
+		PyObject *pyyear = PySequence_GetItem(timetuple, 0);
+		if (pyyear == NULL) return NULL;
+		assert(PyInt_Check(pyyear));
+		year = PyInt_AsLong(pyyear);
+		Py_DECREF(pyyear);
+		if (year < 1900) {
+			PyErr_Format(PyExc_ValueError, "year=%ld is before "
+				     "1900; the datetime strftime() "
+	                             "methods require year >= 1900",
+	                             year);
+	                return NULL;
+		}
+	}
+
 	/* Scan the input format, looking for %z and %Z escapes, building
 	 * a new format.  Since computing the replacements for those codes
 	 * is expensive, don't unless they're actually used.