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

[Guido van Rossum]

On Wed, Jan 5, 2011 at 12:58 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> 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?

Because that's what the datetime module accepts.

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

Shouldn't the logic be to take the current year into account? By the
time 2070 comes around, I'd expect "70" to refer to 2070, not to 1970.
In fact, I'd expect it to refer to 2070 long before 2070 comes around.

All of which makes me think that this is better left to the app, which
can decide for itself whether it is more important to represent dates
in the future or dates in the past.

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

Yeah, but who sets that variable?

Couldn't we make it so that if PYTHONY2K is set (even to the empty
string) it wins, but if it's not set (at all) we can make the default
adjust over time?

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



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