time, calendar, datetime, etc

[John Roth]

"Andrew Dalke" <adalke at mindspring.com> wrote in message
news:bgejrq$i54$1 at slb6.atl.mindspring.net...
> Ben Finney:

[...]

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

Several turns out to be one revision, and I don't think that they
got it right either. From what I see, the Python datetime library
is actually more complicated than the Java library: it's certainly
got more classes, although they seem to be better designed.

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

For the most part, the applications that need to be aware of leap
seconds are the ones that communicate with other servers that
are aware of leap seconds, and can report them. As far as I'm
aware, leap seconds are a thing of the past anyway: they proved
to be more trouble than they were worth to anyone.

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

Nothing at all - I'd expect to see some sort of an extension to
handle those issues, just as I'd expect to see an extension if you
wanted to use the proleptic Julian calendar, the Chinese calendar,
the civil Moslem calendar, the Jewish calendar, and on and on
and on.

I'd also expect to see some sort of reasonably well thought out framework
where those extensions could simply be plugged in and just work.

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

Where was it in March? [grin]. Answer. It depends on where is.

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

I'm certainly not objecting to that. That's the interface to a time
system that everyone expects, and other objectives should quite
properly be implemented by some sort of extensions. My objection
is to exactly one implementation decision: to limit the time range
at 1AD. That is, to use the vernacular, a show-stopper. It means
that the core of the library has to be reworked if you want to deal
with dates before 1AD. It has nothing to do with the external
interfaces, nor does it have anything to do with whether the package
has the ability to use proleptic Julian dates, Chinese dates, Muslim
civil calendar dates, or anything else.

I don't have the time to look into how difficult it would be
to change that. Right now, I'm working on bringing the Python
version of FIT up to the March Java release, and integrating
it with FitNesse. Maybe when I get back to my astrology
programming. My application date package works for what
I need it to do; it just seems that I can't abandon it for the
standard Python library package. [Sigh.]

John Roth

>
> Ahhh, I shoulda been a philosopher.  :)
>
>                     Andrew
>                     dalke at dalkescientific.com
>
>