On Wed, Jan 5, 2011 at 6:46 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum <guido@python.org> wrote:
I'm sorry, but at this point I'm totally confused about what you're asking or proposing. You keep referring to various implementation details and behaviors. Maybe if you summarized how the latest implementation (say python 3.2) works and what you propose to change
I'll try. The current implementation is of time.asctime and time.strftime is roughly
if y < 1900: if accept2dyear: if 69 <= y <= 99: y += 1900 elif 0 <= y <= 68: y += 2000 else: raise ValueError("year out of range") else: raise ValueError("year out of range") # call system function with tm_year = y - 1900
I propose to change that to
if y < 1000: if accept2dyear: if 69 <= y <= 99: y += 1900 elif 0 <= y <= 68: y += 2000 else: raise ValueError("year out of range") # call system function with tm_year = y - 1900
The new logic doesn't look right, am I right that this is what you meant? if accept2dyear and 0 <= y < 100: (convert to year >= 1970) if y < 1000: raise ... But what guarantees do we have that the system functions accept negative values for tm_year on all relevant platforms? The 1000 limit still seems pretty arbitrary to me -- if it's only because you don't want to decide whether to use leading spaces or zeros for numbers shorter than 4 digits, let me propose leading zeros since we use those uniformly for months, days, hours, minutes and seconds < 10, and then you can make the year range accepted the same for these as for datetime (i.e. 1 <= y <= 9999). Tim Peters picked those at least in part because they are right round numbers... -- --Guido van Rossum (python.org/~guido)