time, calendar, datetime, etc

[Andrew Dalke]

John Roth:
> I also wonder why anyone made the choice to set the year origin at
> 1AD? That decision, by itself, makes it almost unusable for my hobby
> (astrological software, which is basically astronomical software
> with a different focus.) Astronomical dates are always measured
> in days since 4700 and something BC.

Well, if you're doing astronomical time, wouldn't you just add 4700
and something years and 12 hours (as I recall, astronomers have a
12 hours offset because they observe at night and don't want to have
to change the date (or forget to change the date) part way though.)
How is that unusable?

Why would supporing you be reasonable to the other 99+% of the
users who don't care about doing astronomical measurements, nor
even about the "was there a year 0?" debate.

And as for unusable, bah.  The nuances of time are very sublte.
Ivan Van Laningham at the Houston conference ('98, I think) gave
a paper on using Python for the Mayan calendar.  Even if Python
were to use astronomical time as its basis, that code wouldn't handle
his needs - eg, he wanted to know when the Mayan calendar repeats
itself.  Answer?  Once every
2549465048574470321568539870223503965392934390771449170872386445565969718817
5919250180245133376000
years.  His paper is at
http://www.foretec.com/python/workshops/1998-11/proceedings/papers/laningham
/laningham.html
and it was a very enjoyable talk.

For another example, to be really precise, a datetime module needs
to support leap seconds, so that  "23:59:60" is, at times, valid.  But
Python's datetime module doesn't allow that.

And if it did, it would almost certainly break code written by people
who didn't know there could be 61 seconds in a minute.

So in summary, almost no one needs the functionality beyond what
the standard library has, supporting each and every specialized niche
makes for more complex code, and more complex code means people
who do "normal" programming are much more likely to run into problems
and make the code more likely to break.

                    Andrew
                    dalke at dalkescientific.com