On Wed, Jan 5, 2011 at 10:12 AM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou <solip...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com