pep proposal : A date object for the standard library

Harald Hanche-Olsen hanche at math.ntnu.no
Fri Dec 7 23:30:35 CET 2001


+ s.keim at laposte.net (sebastien):

| KS>It might be useful to express the time in TAI rather than GMT,
| KS>although that distinction ceases to be meaningful outside of modern
| KS>times.
| Could you give me more explanations? I suppose that what is called
| GMT in computer litteracy is in fact TAI.

No.  TAI is French <wink> for International Atomic Time, which is a
simple, linear time scale based on the best efforts of the time
keepers of various countries to build, maintain, operate and
synchronise the best clocks they can manage to make.  The spinning
Earth is a very poor clock in comparison, so one also keeps a clock
called UTC (French for Coordinated Universal Time) which always
differs from TAI by a whole number of seconds.  When the "rotating
Earth clock" (UT1, really, but let's not get technical here) becomes
something like 3/4 of a second off from UTC, a leap second is added to
UTC.

UTC is the time that is often called GMT, though the latter name is
strictly speaking not correct anymore.  Before atomic clocks, BTW,
there was ephemeris time, which played the same role as TAI does
today.  It was based on astronomical observations of the moon and
planets, whose orbits are predictable to a far greater extent than the
rotational state of our planet.

There are some problems with using a seconds count as the basis for
calendrical calculations.  A big one is that nobody knows when leap
seconds will happen in the future.  So you might schedule an event for
the time 2038-01-19 03:14:08 UTC, but you cannot know how many seconds
that is from now, or (equivalently, given that you know when "now" is)
what it will be in TAI.  You might choose to go the way of most unixes
do and pretend that leap seconds don't exist, but that is of course
problematic in case you do care about them.

I think that keeping calendrical calculations and time issues strictly
separate is a good idea myself.  I would even go so far as to suggest
a completely separate module just for dates and calendars.  The
advantage is that you can deal with that without even getting into the
mess of leap seconds, time zones and daylight saving time.  Leave that
for another module.  An advantage of this scheme is that a date module
has at least a chance of becoming simple enough to become a part of
python.  I will make no such assertions about time.

doing-one-can-of-worms-at-a-time-ly y'rs,

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?



More information about the Python-list mailing list