time, calendar, datetime, etc

[John Roth]

"Andrew Dalke" <adalke at mindspring.com> wrote in message
news:bgcr5a$8ac$1 at slb9.atl.mindspring.net...
> 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?

Because I need to be able to deal with BC dates, obviously. Fudging
the base date won't handle that.

> 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.

Mostly because I don't see a particular reason for the actual
decision tha was reached.

> 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.

There are a number of "Mayan" calendars; it's a very complicated
subject. I had no objection to using the proleptic Gregorian calendar
for display: you have to use something, and that's almost universally
used. If you do any kind of historical research, you suddenly discover
that what you thought you knew about dates doesn't work in practice,
even in Western Europe. This is why astronomical dating is important:
it provides a single, well understood and accepted dating system that
can be tied to the (unfortunatelly rare) comments about astronomical
phenomena, and it goes back far enough that all dates of historical
interest are positive numbers.

>
> 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.

Usually, that's handled by a separate conversion from UT (Universal
Time) to ET (Ephemeris time.) And leap seconds are a modern innovation:
for accuracy there are a number of correction formulae that you apply
depending on the exact historical era in question.
>
> 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.

Funny about that: the Unix system specifications that I've seen
have always said that there may be 61 seconds in a minute. It's built
into the API.

> 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, you've brought in an army of straw men. The **ONLY**
thing I was criticising was the decision to limit the module to dates
beginning with 1 AD. All the other things you bring up are things that
I either don't care about, or that I agree shouldn't complicate the API.

John Roth
>
>                     Andrew
>                     dalke at dalkescientific.com
>
>