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