Issue #1777412: extended year range of strftime down to 1000.
diff --git a/Modules/_datetimemodule.c b/Modules/_datetimemodule.c
index 16964d8..6195940 100644
--- a/Modules/_datetimemodule.c
+++ b/Modules/_datetimemodule.c
@@ -1166,10 +1166,10 @@
if (!pin)
return NULL;
- /* Give up if the year is before 1900.
+ /* Give up if the year is before 1000.
* 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
+ * years before 1000 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
@@ -1182,10 +1182,10 @@
assert(PyLong_Check(pyyear));
year = PyLong_AsLong(pyyear);
Py_DECREF(pyyear);
- if (year < 1900) {
+ if (year < 1000) {
PyErr_Format(PyExc_ValueError, "year=%ld is before "
- "1900; the datetime strftime() "
- "methods require year >= 1900",
+ "1000; the datetime strftime() "
+ "methods require year >= 1000",
year);
return NULL;
}
@@ -3663,7 +3663,7 @@
/* Python's strftime does insane things with the year part of the
* timetuple. The year is forced to (the otherwise nonsensical)
- * 1900 to worm around that.
+ * 1900 to work around that.
*/
tuple = Py_BuildValue("iiiiiiiii",
1900, 1, 1, /* year, month, day */
diff --git a/Modules/timemodule.c b/Modules/timemodule.c
index 94265c6..5732f15 100644
--- a/Modules/timemodule.c
+++ b/Modules/timemodule.c
@@ -471,9 +471,9 @@
return NULL;
/* XXX: Reportedly, some systems have issues formating dates prior to year
- * 1900. These systems should be identified and this check should be
+ * 1000. These systems should be identified and this check should be
* moved to appropriate system specific section below. */
- if (buf.tm_year < 0) {
+ if (buf.tm_year < -900) {
PyErr_Format(PyExc_ValueError, "year=%d is before 1900; "
"the strftime() method requires year >= 1900",
buf.tm_year + 1900);