[Python-Dev] Checking input range in time.asctime and time.ctime (original) (raw)

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Jan 5 21:58:07 CET 2011

On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum <guido at python.org> wrote: ..

extending accepted range is a borderline case IMO. I like accepting all years >= 1 when accept2dyear is False.

Why >= 1? Shouldn't it be >= 1900 - maxint? Also, what is your take on always accepting [1000 - 1899]?

Now, to play the devil's advocate a little, with the new logic accept2dyear would actually mean "map 2-digit year" because 2-digit years will be accepted when accept2dyear is False, just not mapped to reasonable range. I don't have much of a problem with having a deprecated setting that does not have the meaning that its name suggests. (At the moment accept2dyear = True is actually treated as accept2dyear = 0!) I am mentioning this because I think the logic should be

if accept2dyear: if 0 <= y < 69: y += 2000 elif 69 <= y < 100: y += 1900 elif 100 <= y < 1000: raise ValueError("3-digit year in map 2-digit year mode")

and even the last elif may not be necessary.

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

Note that time.accept2dyear is controlled by PYTHONY2K environment variable. If we switch the default, we may need to add a variable with the opposite meaning.

Maybe we can add a deprecation warning in 3.2 when a 2d year is actually received?

+1, but only when with accept2dyear = 1. When accept2dyear = 0, any year should just pass through and this should eventually become the only behavior.

The posix standard notwithstanding they should be rare, and it would be better to make this the app's responsibility if we could.

..

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?

Note that this is already done at least in two places in stdlib: in email package parsedate_tz and in _strptime.py. Given that the POSIX convention is arbitrary and unintuitive, maybe we should provide time.posix2dyear() function for this purpose.

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).

Existing stdlib date parsing code already does that and ignores accept2dyear setting.

More information about the Python-Dev mailing list