"""
> 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].