diff options
| author | Tim Peters <tim.peters@gmail.com> | 2002-12-22 20:34:46 (GMT) |
|---|---|---|
| committer | Tim Peters <tim.peters@gmail.com> | 2002-12-22 20:34:46 (GMT) |
| commit | 83b85f1d6cce999e0d85f669df71a520632a4c87 (patch) | |
| tree | 3a2fb24900f4ecaaf846bde6923dda0c42b14b69 | |
| parent | 14b6941197ca0368f78be6d87169047245f915b8 (diff) | |
| download | cpython-83b85f1d6cce999e0d85f669df71a520632a4c87.zip cpython-83b85f1d6cce999e0d85f669df71a520632a4c87.tar.gz cpython-83b85f1d6cce999e0d85f669df71a520632a4c87.tar.bz2 | |
Python's strftime implementation does strange things with the year,
such that the datetime tests failed if the envar PYTHON2K was set.
This is an utter mess, and the datetime module's strftime functions
inherit it. I suspect that, regardless of the PYTHON2K setting, and
regardless of platform limitations, the datetime strftime wrappers
will end up delivering nonsense results (or bogus exceptions) for
any year before 1900. I should probably just refuse to accept years
earlier than that -- else we'll have to implement strftime() by hand.
| -rw-r--r-- | Modules/datetimemodule.c | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/Modules/datetimemodule.c b/Modules/datetimemodule.c index 73c1764..28f61bd 100644 --- a/Modules/datetimemodule.c +++ b/Modules/datetimemodule.c @@ -3518,8 +3518,12 @@ time_strftime(PyDateTime_Time *self, PyObject *args, PyObject *kw) &PyString_Type, &format)) return NULL; + /* 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. + */ tuple = Py_BuildValue("iiiiiiiii", - 0, 0, 0, /* year, month, day */ + 1900, 0, 0, /* year, month, day */ TIME_GET_HOUR(self), TIME_GET_MINUTE(self), TIME_GET_SECOND(self), |