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

[Alexander Belopolsky]

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.