Issue #1777412: extended year range of strftime down to 1000.

This commit is contained in:
Alexander Belopolsky 2011-01-08 00:13:34 +00:00
parent 9253214fd9
commit b8bb4664fc
4 changed files with 15 additions and 15 deletions

View File

@ -173,9 +173,9 @@ def _format_time(hh, mm, ss, us):
# Correctly substitute for %z and %Z escapes in strftime formats.
def _wrap_strftime(object, format, timetuple):
year = timetuple[0]
if year < 1900:
raise ValueError("year=%d is before 1900; the datetime strftime() "
"methods require year >= 1900" % year)
if year < 1000:
raise ValueError("year=%d is before 1000; the datetime strftime() "
"methods require year >= 1000" % year)
# Don't call utcoffset() or tzname() unless actually needed.
freplace = None # the string to use for %f
zreplace = None # the string to use for %z
@ -1189,7 +1189,7 @@ class time:
"""Format using strftime(). The date part of the timestamp passed
to underlying strftime should not be used.
"""
# The year must be >= 1900 else Python's strftime implementation
# The year must be >= 1000 else Python's strftime implementation
# can raise a bogus exception.
timetuple = (1900, 1, 1,
self._hour, self._minute, self._second,

View File

@ -1284,10 +1284,10 @@ class TestDate(HarmlessMixedComparison, unittest.TestCase):
self.assertTrue(self.theclass.max)
def test_strftime_out_of_range(self):
# For nasty technical reasons, we can't handle years before 1900.
# For nasty technical reasons, we can't handle years before 1000.
cls = self.theclass
self.assertEqual(cls(1900, 1, 1).strftime("%Y"), "1900")
for y in 1, 49, 51, 99, 100, 1000, 1899:
self.assertEqual(cls(1000, 1, 1).strftime("%Y"), "1000")
for y in 1, 49, 51, 99, 100, 999:
self.assertRaises(ValueError, cls(y, 1, 1).strftime, "%Y")
def test_replace(self):

View File

@ -1166,10 +1166,10 @@ wrap_strftime(PyObject *object, PyObject *format, PyObject *timetuple,
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 @@ wrap_strftime(PyObject *object, PyObject *format, PyObject *timetuple,
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 @@ time_strftime(PyDateTime_Time *self, PyObject *args, PyObject *kw)
/* 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 */

View File

@ -471,9 +471,9 @@ time_strftime(PyObject *self, PyObject *args)
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);