On Wed, Jan 5, 2011 at 6:46 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum <guido at 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)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4