pep proposal : A date object for the standard library

John Roth johnroth at ameritech.net
Thu Dec 6 20:45:05 EST 2001


"Greg Ewing" <greg at cosc.canterbury.ac.nz> wrote in message
news:3C100EFF.6EEA6C7A at cosc.canterbury.ac.nz...
> Chris Barker wrote:
> >
> > I would
> > argue that applications that deal with nanoseconds are of a
different
> > breed than those that deal with day, month, year type calculations.
>
> I'm not sure that's true. Consider something like generating
> timestamps for transactions. They need to be unique over
> a long time, and need quite fine-grained accuracy as well,
> certainly much less than a second. Even microseconds might
> be too coarse -- today's processors can do a LOT of
> computation in a microsecond!

I think it is true. You basically have two different
kinds of date/time calculations: those based on the
calendar, which is ultimately based on the rotation of
the Earth on its axis, and those based on a uniform measure
of time. In general, physicists and similar people
involved with the real world need the second, people
involved with business and such concerns need the
first. It's possible to translate between them, but not
easy.

Timestamps are a special case: they usually need to
be translatable into calendar terms, but they need more
resolution than we normally give calendar based dates
and times.

For calendar based dates, I would suggest using
the astronomical Julian date as the basis. It's well
known and has published algorithms for translating
from and to just about every known calendar
system.

John Roth





More information about the Python-list mailing list