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

Guido van Rossum guido at python.org
Wed Jan 5 20:19:34 CET 2011

On Wed, Jan 5, 2011 at 10:12 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> ..
>> Couldn't we deprecate and remove time.accept2dyear? It has been there
>> for "backward compatibility" since Python 1.5.2.
> It will be useful for another 50 years or so.  (POSIX 2-digit years
> cover 1969 - 2068.)  In any case, this is not an option for 3.2 while
> extending accepted range is a borderline case IMO.

I like accepting all years >= 1 when accept2dyear is False.

In 3.3 we should switch its default value to False (in addition to the
keyword arg you are proposing below, maybe).

Maybe we can add a deprecation warning in 3.2 when a 2d year is
actually received? The posix standard notwithstanding they should be
rare, and it would be better to make this the app's responsibility if
we could.

>> 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.
> Yes, for 3.3 I am going to propose an optional accept2dyear argument
> to time.{asctime, strftime} in addition to or instead of a global
> variable.  This is also necessary to implement a pure python version
> of datetime.strftime that would support full range of datetime.  See
> http://bugs.python.org/issue1777412 .

I wish we didn't have to do that -- isn't it easy enough for the app
to do the 2d -> 4d conversion itself before calling the library
function? The only exception would be when parsing a string -- but
strptime can tell whether a 2d or 4d year is requested by the format
code (%y or %Y).

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list