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

[Alexander Belopolsky]

On Wed, Jan 5, 2011 at 6:12 PM, Guido van Rossum <guido at python.org> wrote:
..
> If they both impose some arbitrary limits, it would be easier for
> users to remember the limits if they were the same for both modules.
>
Unfortunately, that is not possible on 32-bit systems where range
supported by say time.ctime() is limited by the range of time_t.

> (In fact datetime.strftime() is currently limited by what
> time.strftime() can handle -- more linkage.)
>
Not really.  There is a patch at http://bugs.python.org/issue1777412
that removes this limit for datetime.strftime.  There is an issue for
pure python implementation that does depend on time.strftime(), but
that can be addressed in several ways including ignoring it until time
modules is fixed.

..
>> Furthermore,
>> this thread started with me arguing that year > 9999 should raise
>> ValueError and if we wanted to restrict time module functions to
>> datetime-supported year range, that would be the right thing to do.
>
> I'd be fine with a ValueError too, if that's what it takes to align
> the two modules better.
>

Do you want to *add* year range checks to say time.localtime(t) so
that it would not produce time tuple with out of range year?  IMO,
range checks are justified when they allow simpler implementation.  As
far as users are concerned, I don't think anyone would care about
precise limits if they are wider than [1000 - 9999].


..
>> This said, I would be perfectly happy with just changing y >= 1900 to
>> y >= 1000.  Doing so will spare us from making a choice between
>> '0012', '12' and '   12' in time.asctime().   Time-series that extend
>> back to 19th century are not unheard of and in many places modern
>> calendar was already in use back then.  Anything prior to year 1000
>> would certainly require a custom calendar module anyways.
>
> Yeah, but datetime takes a position here (arbitrarily extending the
> Gregorian calendar all the way back to the year 1, and forward to the
> year 9999). I'd be happiest if time took the same position.

Doesn't it already?  On my system,

$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

but

>>> (datetime(1752, 9, 2) - datetime(1970,1,1))//timedelta(0, 1)
-6858259200
>>> time.gmtime(-6858259200)[:3]
(1752, 9, 2)
>>> datetime(1752, 9, 2).weekday()
5
>>> time.gmtime(-6858259200).tm_wday
5