homepage

"""
> http://docs.python.org/library/time.html#time-y2kissues
> "Values 100–1899 are always illegal."
Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1] (tm_year in [-2147483648; 2147481747]). If time.accept2dyear=False, we should at least accept years in [1; 9999]. The system libc would raise an error (return NULL) if it doesn't know how to format years older than 1900.
""" -- Victor Stinner at msg12516 

> The system libc would raise an error (return NULL) if it doesn't know
> how to format years older than 1900.
As experience with asctime has shown, system libc can do whatever it pleases with out of range values including overrunning a fixed size buffer, returning non-sensical values etc. However, now that we have control over asctime implemetation (see issue 8013), I don't see any problem in supporting at least year > 999 in time.asctime and time.ctime. (Supporting full [1900-maxint, maxint] range would involve a decision on whether to fill < 4-digit values.) Some extra care would be required for time.strftime() because some systems may not support year < 1900 as well as others.
It looks like POSIX does not make any strong mandates:
"tm_year is a signed value; therefore, years before 1900 may be represented." 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html
and regardless of what POSIX or C standards have to say, this is the area where systems a known to have spotty compliance records.

I am attaching a patch. While working on the patch, I noticed that although time.accept2dyear is documented as boolean, the current code expects int and treats any non-int including True as 0:
>>> time.accept2dyear = True; time.asctime((99,) + (0,)*8)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ValueError: year >= 1900 required
>>> time.accept2dyear = 1; time.asctime((99,) + (0,)*8)
'Mon Jan 1 00:00:00 1999'
This is clearly a bug. (Although Y2K note contradicts time.accept2dyear documentation.)
Supporting year < 1900 would be a feature in my view, but I agree with SilentGhost that once we extended support to 5+ digit years, it is odd to keep year >= 1900 restriction.

On Tue, Jan 4, 2011 at 1:30 PM, Alexander Belopolsky
<report@bugs.python.org> wrote:
..
> This is clearly a bug. (Although Y2K note contradicts time.accept2dyear documentation.)
>
PyObject_IsTrue() may fail - this is probably the reason for the
current odd logic. My patch should be fixed top respect that, but I
still maintain that time.accept2dyear = True should work as expected.
(Would also make True the default rather 1.)

But if it fails, why not just let it fail?

On Tue, Jan 4, 2011 at 1:49 PM, Georg Brandl <report@bugs.python.org> wrote:
..
> But if it fails, why not just let it fail?
>
Sure. That's what I meant by fixing the patch. See new patch attached.

Attached patch, issue10827b.diff, fixes the accept2dyear = True issue and removes unnecessary struct_time to tuple conversion, but otherwise does not change the Y2K behavior. The code handling accept2dyear is refactored so that it is now easy to accept y < 1900 in accept2dyear = False mode. The patch also includes unit tests.

Attached patch, issue10827c.diff, implements the following logic in gettmarg:
 /* If year is specified with less that 4 digits, its interpretation 
 * depends on the accept2dyear value. 
 * 
 * If accept2dyear is true (default), a backward compatibility behavior is 
 * invoked as follows: 
 * 
 * - for 2-digit year, century is guessed according to POSIX rules for 
 * %y strptime format: 21st century for y < 69, 20th century 
 * otherwise. A deprecation warning is issued when century 
 * information is guessed in this way. 
 * 
 * - for 3-digit or negative year, a ValueError exception is raised. 
 * 
 * If accept2dyear is false (set by the program or as a result of a 
 * non-empty value assigned to PYTHONY2K environment variable) all year 
 * values are interpreted as given. 
 */
It is easy to restore year >= 1900 limit for strftime, but I would rather add tests that time.strftime either produces correct values or raises ValueError and see if buildbots discover any platform bugs.

Committed in 87829.
I added a year >= 1900 check in time.strftime for now because removing or relaxing this limit should be done in coordination with similar datetime module issue. See #1777412.
See also python-dev discussion starting at
http://mail.python.org/pipermail/python-dev/2011-January/107186.html 

Commit link: r87829 

I tried time.asctime() on Windows 32 bits (compiled with Visual Studio) with accept2dyear=False: it accepts years in [-2^31; 2^31-1], cool.

time.asctime(), time.ctime() and time.strftime() are no more not limited for the year field if accept2dyear=0. Except with Visual Studio or on Solaris: the year is limited to the range [1; 9999].