@@ -1166,10 +1166,10 @@ wrap_strftime(PyObject *object, PyObject *format, PyObject *timetuple,
11661166 if (!pin )
11671167 return NULL ;
11681168
1169- /* Give up if the year is before 1900 .
1169+ /* Give up if the year is before 1000 .
11701170 * Python strftime() plays games with the year, and different
11711171 * games depending on whether envar PYTHON2K is set. This makes
1172- * years before 1900 a nightmare, even if the platform strftime
1172+ * years before 1000 a nightmare, even if the platform strftime
11731173 * supports them (and not all do).
11741174 * We could get a lot farther here by avoiding Python's strftime
11751175 * wrapper and calling the C strftime() directly, but that isn't
@@ -1182,10 +1182,10 @@ wrap_strftime(PyObject *object, PyObject *format, PyObject *timetuple,
11821182 assert (PyLong_Check (pyyear ));
11831183 year = PyLong_AsLong (pyyear );
11841184 Py_DECREF (pyyear );
1185- if (year < 1900 ) {
1185+ if (year < 1000 ) {
11861186 PyErr_Format (PyExc_ValueError , "year=%ld is before "
1187- "1900 ; the datetime strftime() "
1188- "methods require year >= 1900 " ,
1187+ "1000 ; the datetime strftime() "
1188+ "methods require year >= 1000 " ,
11891189 year );
11901190 return NULL ;
11911191 }
@@ -3663,7 +3663,7 @@ time_strftime(PyDateTime_Time *self, PyObject *args, PyObject *kw)
36633663
36643664 /* Python's strftime does insane things with the year part of the
36653665 * timetuple. The year is forced to (the otherwise nonsensical)
3666- * 1900 to worm around that.
3666+ * 1900 to work around that.
36673667 */
36683668 tuple = Py_BuildValue ("iiiiiiiii" ,
36693669 1900 , 1 , 1 , /* year, month, day */
0 commit comments