This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients SilentGhost, belopolsky, vstinner
Date 2011-01-04.17:30:02
SpamBayes Score 7.311985e-07
Marked as misclassified No
Message-id <1294162213.49.0.928737927372.issue10827@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2011-01-04 17:30:13belopolskysetrecipients: + belopolsky, vstinner, SilentGhost
2011-01-04 17:30:13belopolskysetmessageid: <1294162213.49.0.928737927372.issue10827@psf.upfronthosting.co.za>
2011-01-04 17:30:03belopolskylinkissue10827 messages
2011-01-04 17:30:02belopolskycreate