time, calendar, datetime, etc

[Tim Peters]

[Andrew Dalke]
> ...
> The datetime module needs a 0 point (the creation of the universe
> being rather long ago and the exact time not well known).  Given the
> questions of "when is year 0?" in different calendar systems, it's easy
> for me to understand why Jan. 1st, 1AD is a good starting point.
> (Easier than Jan 1st, 1970 - I prefered the Mac's epoch of 1900.)

There was a specific reason for picking "year 1":  that makes datetime's
date ordinals identical to those used in the base proleptic Gregorian
calendar in Dershowitz and Reingold's highly regarded "Calendrical
Calculations":

    http://emr.cs.iit.edu/home/reingold/calendar-book/second-edition/

So people who want umpteen kinds of calendars Guido doesn't care about can
look up algorithms in that book to do conversion to and from datetime's view
of reality.  For that reason alone, it was a better choice than most.  In
addition, since an explicit goal of datetime was fast extraction of fields,
we simply store the year as given (e.g., 2003 is stored as 2003).  This also
works well for fast comparisons.  Something missed in this discussion so far
is that commercial applications deal in countless thousands of dates and
datetimes -- formatting, sorting and indexing speed are important to them.
Important enough to Zope Corp to pay the substantial bill for developing
this code, anyway.

i-hear-guido-doesn't-come-cheap-ly y'rs  - tim