Tue, 17 Jun 2003 18:20:32 -0400
John Meacham wrote:
> as for the leap second issue, I suggest a simple solution inspired by
That is a mirror or a local copy. DJB's page on UTC and TAI is at
> ClockTimes and TimeDiffs are ALWAYS TAI with an epoch of 1970-01-01
> 00:00:10 TAI (to correspond to other libraries). a second is always a
The UTC second and the TAI second are precisely the same interval, and
"tick" at the same time; TAI and UTC always differ by an integral number
of seconds. TAI and UT0/UT1/UT2 are different.
> this greatly simplified the internals as simple arithmetic on
> integers is always correct.
> the only time UTC and leap seconds should come into play is when
> converting to or from a CalanderTime since UTC is meant to be a
> human-consumable notion of time, not a precise one.
I'm not sure if this is really a correct notion of UTC.
TAI is atomic time, and ticks at a precisely defined rate. UT1 is
corrected solar time (actually sidereal time converted to solar time and
corrected), and due to quirks in the earth's rotation, is not constant.
UTC is a comprimise between the two. UTC ticks at TAI's rate, but is
corrected with leap seconds to it within +- 0.9 seconds of UT1.
> We will have to
> assume that an oracle exists to tell us which years had leap seconds in
> them, but such information is required by any scheme which works with
> UTC, many systems provide them and it is easy enough to embed a table.
I have to dig out my files on this (they are currently MIA due to job
changes), but I believe the problem with this approach has to do with
updating the leap second table in deployed systems. Also, all time
broadcasts are by international agreement UTC (GPS may be different, but
I can't remember), so anything a computer receives is going to be UTC.
TAI may be the best thing to do in an ideal world, but the world is
pretty much stuck with UTC.
Matthew Donadio (firstname.lastname@example.org)