time, calendar, datetime, etc

Andrew Dalke adalke at mindspring.com
Fri Aug 1 16:55:09 EDT 2003


Ben Finney:
> It is astronomy (and, before it, astrology) that has driven the
> standardisation of time for many centuries; anyone wanting to use a
> standardised time system is using one based on astronomical imperatives.

And here I thought it was the railroads which drove the standarization.
Before then, each city had its own noon, and the only standarization
between places was for dates.  (Except also depending on your faith.)
Granted, "noon" is an astronomical measurement, just that the actual
time changed from place to place.

Kinda depends on what you call "standard".  And before trains,
ships wanted to know the time to know the location, and monks
wanted to know when to pray, and ..

So again I say, most people don't care that much about the time.
A useful library doesn't need to incorporate all the details needed by
astronomers, historians, etc.

> Anyone who wants to deal with dates BC (in the Gregorian calendar) cares
> about the "was there a year 0?" question (answer: not in the Gregorian
> calendar, there wasn't).
>
> So it seems you're dismissing a large sector of users: those who deal
> with dates before 1AD, and those who want to use worldwide date/time
> standards.

That's not in disagreement with what I said.  I said (though more
loosely) 99+% of the people who are affected by the restrictions of
datetime won't notice a problem.  The remaining <1% might still be
"a large sector of users".  For them I say, develop a library which
deals with all that complexity (or use the mx package).

Python doesn't try to support all numerical systems - that's why
Numeric exists.  Would those users like Numeric support in core
Python?  Probably.  Are there more Numeric users than people
who need a detailed datetime library?  Almost certainly yes.  So
I aks again, what makes datetime with B.C. support, leap seconds,
etc. important enough to justify inclusion in Python's standard library.

By comparison, a friend of mine mentioned that the Java time library,
which does try to include all these complexities, has gone through
several iterations to get where it is now and is complicated to use
because it tries to get all the details right.

> Such people would run into trouble when leap seconds occurred anyway;

Ha!  None of my code ever used leap seconds, and in my 15 years
or so of software development, no one ever filed a bug report on it.
And on the plus side, I don't have to distribute an update when there
is an new leap second.  That's because for just about everyone in the
world, a difference of a few seconds doesn't make a difference.
C'mon - the clocks in my house are +/- a few minutes!

It's only the very small number of people who care about the differences
between UTC, UT1, GPS, TAI, and all those other highly specialized
time systems that care about these sorts of details ("care" == "affects
them in any meaningful way"), so what's wrong with those people
developing a specialized library to handle those issues?

> keeping the datetime module ignorant of it just means the problems will
> not be dealt with when the program is designed (when it is easy to
> correct) but rather be thrust in their face when a leap second occurs
> (presumably when the program has been long forgotten about and the
> original programmer possibly departed).

Easy to correct?  Okay, the last leap second was added 1/1/99.  Did
you upgrade some data file then to include that change?  Or did your
software fix itself automatically?  Or did you just synch your machine
to network time and figure it was part of normal clock skew?


> Quite the reverse.  If the standard library supported things like leap
> seconds, absence-of-year-zero, and Julian dates, it would be wrapped up
> in one place where programmers could use it without having to know about
> the implementation complexities.

Implement that library, get people to use it, implement the functionality
of the datetime module using it, make sure it's maintainable and
maintained, petition for its inclusion in Python.

Then again, you could just use mxDateTime.

Here's another view of the issue.  The datetime module implements what
I'll call "vernacular" time.  That is, time as is understood by most people.
24 hours in a day, 60 minutes in an hour, 60 seconds in a day, 365 days
in a year except every 4th year (and hazy idea about something strange
at the century mark, but that's not a problem now).  And then there's
timezones and daylight savings time.  (And no thoughts of "double
daylight savings like the British had during WWII.")

datetime implements vernacular time.  There's a lot of code
which implements vernacular time, because they aren't written
by experts.  To them, 1) datetime makes sense and 2) won't
ever cause problems in real life.

I am one of those people.  I would like to replace my hand-written
code with a standard library.  I want that library to implement *my*
time system, not the so-called real one developed by experts who
worry about variations in the Earth's rotation nor about scholars
who say the first day of the year back in 1000AD was in March.

So a robust datetime library almost certainly must implement
this vernacular time system, if only for completeness.  Consider
'datetime' as the first module for that hypothetical library.  It
definitely is useful as-is.  Now we just have to wait for the rest
of it to be implemented.

Ahhh, I shoulda been a philosopher.  :)

                    Andrew
                    dalke at dalkescientific.com






More information about the Python-list mailing list