[Patches] [ python-Patches-445770 ] Make calendar.py work forever.

noreply@sourceforge.net noreply@sourceforge.net
Wed, 01 Aug 2001 15:20:22 -0700


Patches item #445770, was opened at 2001-07-29 15:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph A Knapka (jknapka)
>Assigned to: Skip Montanaro (montanaro)
Summary: Make calendar.py work forever.

Initial Comment:
Changes to calendar.py (using a lot of code
stolen from Pmw) to make it work for
essentially any date, and handle Julian vs.
Gregorian dating properly. julian=[-1|0|1]
and papal=[0|1] arguments added to many
functions, with appropriate defaults. If
julian==1, Julian dating is used; if julian==0
Gregorian dating is used; if julian==-1
the code decides based on the date which
dating system to use. If papal==1 the Gregorian
reformation is applied in October 1582,
the year of the edict; if papal==0 the
reformation is applied in September 1752,
the year in which Britain applied the change.
julian defaults to -1 and papal to 0, so
normally no one will need to care about
them.

Dependencies on the "time" module have
been removed.

Added functions:
 ymdtojdn(y,m,d) - convert year,month,day to Julian
    day number
 jdntoymd(jdn) - convert jdn to (year,month,day)
    tuple.
 jdntodow(jdn) - compute the day-of-week (0-6)
    of a Julian day number.

Modified all existing code to use the new date and
day-of-week code. So "prcal()" for example does
the right thing.

Testing: it gets the same answers as the "cal"
program for a selection of months between 01/01
and 9999/12, including Oct 1582 and Sept 1752,
when papal=0.

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

Comment By: Joseph A Knapka (jknapka)
Date: 2001-08-01 09:42

Message:
Logged In: YES 
user_id=118570

The current calendar.py code only works after 1900AD. I can
think of a number of applications (library catalogs, or any
other
kind of historical record-keeping, for example) that need to
represent dates before 1900. Furthermore, this code will
work
into the indefinite future, barring further Papal edicts,
whereas
the current calendar.py code is bound by the limitations of
the
"time" module. What's the point of keeping arbitrary
limitations in
the standard library?

Essentially this code was written because I had an
application
that could use it, and I thought it might be a nice
improvement
to the existing calendar code.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-29 15:29

Message:
Logged In: YES 
user_id=6380

Apart from the novelty value, what's the point of supporting
calendars hundreds of years back? Why does this belong in
the standard library?

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

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