[Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900

noreply@sourceforge.net noreply@sourceforge.net
Tue, 21 Aug 2001 18:52:40 -0700


Bugs item #434143, was opened at 2001-06-18 04:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
>Assigned to: Skip Montanaro (montanaro)
Summary: calendar module broken for 1900

Initial Comment:
Hi there, this is a 'feature' I met on both 1.5.2 and
2.1.

>>> import calendar
>>> calendar.prcal(1865)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
ValueError: year out of range (00-99, 1900-*)

(note that the documentation only refers to 1970 as a
possible limit, and does not mention how dates in 00-99
range are processed)

Now if I try to get the calendar for year 1900 (which
is supposed to work according to the message
hereabove), I get

>>> calendar.prcal(1900)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

I guess this is low priority. 

Cheers 

Alexandre Fayolle


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-21 18:52

Message:
Logged In: YES 
user_id=3066

Skip, I think you've got the best solution possible short of
adding "real" calendar and date support to the standard
library.  Please commit your suggested changes and close
this report.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 14:33

Message:
Logged In: YES 
user_id=44345

Fred, I'm tossing this over your fence.  All I proposed was
some documentation changes to more clearly identify the
problem.

Skip


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-26 22:14

Message:
Logged In: NO 

I think the limitations actually stem from the time module,
which depends on the platform you're running. Notice what I
get on linux:

>>> import calendar
>>> a = calendar.calendar(1902)
>>> b = calendar.calendar(1901) 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/calendar.py", line 181, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/local/lib/python2.1/calendar.py", line 87, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/local/lib/python2.1/calendar.py", line 80, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/local/lib/python2.1/calendar.py", line 71, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

Investigating further, I tried the following:

>>> from time import gmtime, mktime
>>> gmtime(sys.maxint * -1)
(1901, 12, 13, 20, 45, 53, 4, 347, 0)

Right there that's suspicious - calendar.calendar() breaks
down in the year generated by gmtime(sys.maxint * -1).

It gets a bit weird below that point...

>>> gmtime(sys.maxint * -1 - 1)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> gmtime(sys.maxint * -1 - 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer subtraction
>>>
>>> # OK, now try coercing the argument to a long.
>>> gmtime(sys.maxint * -1 - 2L)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> mktime(gmtime(sys.maxint * -1 - 2L))
-2147465648.0
>>> mktime(gmtime(sys.maxint * -1 - 1000000L))
-2147465648.0

Looks like we've hit a lower limit there.
It would take a competent C programmer (which I am not) to
determine whether anything could be done about this.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2001-07-19 00:09

Message:
Logged In: YES 
user_id=116727

sounds good to me. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-18 13:14

Message:
Logged In: YES 
user_id=44345

I propose sidestepping this issue by fiddling with the
documentation.  See the attached file time.diff.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-06 11:40

Message:
Logged In: YES 
user_id=44345

calendar.py is a *very* old module.  Version 1.1 has a date
of 
13-Oct-90.  The message about the ranges almost certainly
comes from the days when Guido and his pals at CWI were 
developing Python on Macs.  I just tried:

    time.mktime((1900,1,1,0,0,0,0,0,0))

on my iMac and it works.  If the year is 1899 it generates
the
traceback.  A year of 1 is currently interpreted as 2001.

I'm not sure this is worth fixing, other than to document
the
limitations better.  If you want to display calendars
perhaps
you should look at Marc-Andre Lemburg's mx.DateTime
module, which supports a much wider range of dates.

Skip
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470