time, calendar, datetime, etc

[Andrew Dalke]

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

Ahhh, I see.  I figured you just had dates in Julian, and algorithms
for dealing with dates in Julian, so what you needed was the
ability to deal with present dates (within a few decades at most)
and not define some date in history.

Just to point out though, before 2.3 you couldn't have used Python's
libraries for that either, since the C epoch doesn't handle dates
before 1970.  Instead, you would have used mxDateTime, which
does a good job at this, and still does.

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

To be complete, a datetime library needs to handle a *lot* of details.
That makes the library hard to implement and maintain.  Eg,
what about the days that 'disappeared' between Julian and Gregorian,
leap seconds, and other worries?  Most people don't need that.
For them and me, datetime is good enough.  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.)

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

Well, I don't do historical research.  I'm pretty insular that way.  I
know there are problems in interpreting dates - my religious training
taught me that if nothing else.

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

Understood.  I still maintain that a library which handles all the
specialized datetime issues (historical, religious, astronomical,
navigation, ...) is too complex for inclusion in Python's standard
library.  Specialists should use a specialist's library.  What Python
has is quite good enough for just about everyone's needs.

Put it this way - FixedPoint still isn't part of Python's standard
library even though it's very important for people dealing with
money.  Then again, for most people, floats (!) are good enough.

> 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 it makes sense for Python's standard library to handle all
that?

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

And there's where I learned it from.  Doesn't mean the libraries
support it.  And I'm told the C spec's comment about "double leap
seconds" is based on a misunderstanding and those don't actually exist.

One of the reasons for Python to do it's own datetime code is because
of the broken nature of many platforms native time functions.

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

Then you misunderstand my comments.  You have a very specialized
need to handle dates before 1AD.  Others have a specialized need to
handle leap seconds.  Others need to deal with differences between
UTC, UT1, GPS, and other time systems.  Still others need to handle
complicated timezones (like "double daylight savings", which I think
datetime doesn't handle).  Others again need better than microsecond
timestamps.  For all I know, some need a general relativity
compensation term.

To handle all of these and maintain them as the various time standards
change requires effort.  There aren't all that many people working
on Python.  They decided that most people only need what I termed
'vernacular' time in a previous post in this thread, and that time
system works for 99+% of the datetime needs in the world, and that's
what they implemented.  And I commend the developers for defining
what "good enough" means, and defering perfection to other libraries
and future inclusion.  Very Pythonic.

                     Andrew
                     dalke at dalkescientific.com