RetroSearch Browse

Wed Jan 5 18:48:55 CET 2011 · https://mail.python.org/pipermail/python-dev/2011-January/107238.html

On Wed, 5 Jan 2011 12:33:55 -0500
Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum <guido at python.org> wrote:
> > Given the rule garbage in -> garbage out, I'd do the most useful
> > thing, which would be to produce a longer output string (and update
> > the docs). This would match the behavior of e.g. '%04d' % y when y >
> > 9999. If that means the platform libc asctime/ctime can't be used, too
> > bad.
> 
> I've committed code that does not use platform libc asctime/ctime
> anymore.  Now it seems odd that we support years > 9999 but not years
> < 1900.  A commonly given explanation for rejecting years < 1900 is
> that Python has to support POSIX standard for 2-digit years.  However,
> this support is conditional on the value of time.accept2dyear and
> several people argued that when it is set to false, full range of
> years should be supported.

Couldn't we deprecate and remove time.accept2dyear? It has been there
for "backward compatibility" since Python 1.5.2.

Not to mention that global settings affecting behaviour are generally
bad, since multiple libraries could have conflicting expectations about
it. And parsing times and dates is the kind of thing that a library
will often rely on.

Regards

Antoine.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-January/107238.html below:

[Python-Dev] Checking input range in time.asctime and time.ctime