On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum <gu...@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. _______________________________________________ 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