On Wed, Jan 5, 2011 at 10:12 AM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou <solipsis@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)