time, calendar, datetime, etc

[Andrew Dalke]

John Roth:
> 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.

Then I was just spreading rumor.

I see the following classes in Java:
  java.util.Date
    java.sql.Date
    java.sql.Time
    java.sql.Timestamp
  java.util.Calendar
    java.util.GregorianCalendar
  java.util.Timezone
    java.util.SimpleTimeZone
  java.text.DateFormat
  java.text.SimpleDateFormat

As for Python ones ...
  datetime.timedelta
  datetime.date
  datetime.datetime
  datetime.tzinfo
plus the older ones of
  time.*
  calendar  (mostly useless, IMHO)

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

But those tools don't need support for BC-era dates...

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

There were some dicussions for that - the idea was that datetime and
mxDateTime values should be interoperable.  I don't recall the details
of those plans though ... (searching) ...  Ahh, a thread starts here
  http://mail.python.org/pipermail/python-dev/2003-January/032100.html
but I don't know the conclusion.

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

Sure.  Which is why datetime support for then is hard.

The statement I made in c.l.py years ago was that it's all dependent
on longitude, lattitude, and additude.  Software can handle the first
two, but not the third, at least not without a lot of work and upkeep.

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

I gave an idea of a way to work around that, by using an offset
of 6000 years.  I'll look to there for followup.

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

Does that mean if there was no decision to include datetime in
Python 2.3 then you wouldn't be able to support your application
at all in Python?  Or would you have just decided to use mxDateTime?
If the latter, what's preventing you from doing so now?

                    Andrew
                    dalke at dalkescientific.com