[Python-Dev] Checking input range in time.asctime and time.ctime
Guido van Rossum
guido at python.org
Thu Jan 6 00:12:04 CET 2011
On Wed, Jan 5, 2011 at 2:55 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Wed, Jan 5, 2011 at 4:33 PM, Guido van Rossum <guido at python.org> wrote:
>>> Why >= 1?
>> Because that's what the datetime module accepts.
> What the datetime module accepts is irrelevant here.
Not completely -- they are both about dates and times, there are some
links between them (time tuples are used by both), both have a
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.
(In fact datetime.strftime() is currently limited by what
time.strftime() can handle -- more linkage.)
> Note that
> functions affected by accept2dyear are: time.mktime(), time.asctime(),
> time.strftime() and indirectly time.ctime(). Neither of them produces
> result that is directly usable by the datetime module.
But the latter calls strftime() -- although never with a 2d year of course.
> 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.
> If I understand your "garbage in garbage out" principle correctly,
> time-processig functions should not introduce arbitrary limits unless
> there is a specific reason for them. In datetime module, calendar
> calculations would be too complicated if we had to support date range
> that does not fit in 32-bit integer. There is no such consideration
> in the time module, so we should support whatever the underlying
> system can.
(Except that the *originally* underlying system, libc, was too poorly
standardized and too buggy on some platforms, so we have ended up
reimplementing more and more of it.)
> 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. For
example it would fix the problem that datetime accepts years < 1900
but then you cannot call strftime() on those.
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev