TAI64

[Markus Kuhn]

"D. J. Bernstein" wrote on 1998-05-30 19:44 UTC:
> Markus Kuhn writes:
> > This means, a TAI clock is doomed to go wrong without
> > periodic manual intervention
> 
> You have the situation precisely backwards.
> 
> For computers without any outside input, ticking UTC is impossible by
> definition.

Yes, but your next sentence shows that you misunderstood the reason why:

> Ticking TAI requires nothing more than an internal clock.

No. The speed with which UTC and TAI drift apart is two orders
of magnitude smaller than the frequency error of the majority of
computer clocks out there. Your "computers without any outside input"
are after a couple of months *far* away from both TAI and UTC. These
computers are therefore not of any concern here, because their
operators obviously are not concerned about the accuracy of their
time. Ok, so now we are only talking about computers *with* automatic
outside time input here. These usually receive UTC today, because
UTC is as specified in the various ITU-R TF.* recommendations the
time scale used for international time and frequency broadcasting
signals. UTC (but not TAI) is broadcasted by WWV, DCF77, DVB-SI,
DAB, various teletext carriers, NTP, and many more. Only navigation
systems such as Omega and GPS provide you with TAI, in the case
of GPS, both scales are provided.

> Leap seconds are announced several months in advance.

Yes. On a circular letter and on a web page by IERS and USNO.
Feeding this information into computers then requires manual
intervention unless we establish some leap second history update
protocol for all computers on this planet. I can't believe that
in the forseeable future more than a small minority of installed
systems will get this information in time. Therefore, any practically
usable timescale must today be derived from UTC and not from TAI.
This is what NTP does and this is what POSIX/Unix does for very good
reasons.

> > Therefore, I favour UTC as a timescale in computer applications.
> 
> You have been outvoted by thousands of programmers who subtract UNIX
> times to compute real-time differences.

You are either mixing up concepts here completely, or you are
quite inexperienced in timing issues. In order to understand
what "thousands on Unix programmers" are doing, you should have a look at
section 2.2.2.113 of POSIX.1 (ISO/IEC 9945-1:1996 or ANSI/IEEE Std
1003.1-1996):

The POSIX time_t scale is a count of seconds since the epoch, where the
term "seconds since the epoch" is strictly defined in a way that confuses
people who haven't read the spec carefully: We do not mean the real number of
seconds, but the seconds without counting inserted leap seconds. time_t is
a UTC scale encoding according to the following algorithm: Let
a struct tm contain what a UTC clock displays. Then the
corresponding time_t value is determined by

  tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
  (tm_year-70)*31_536_000 + ((tm_year - 69)/4)*86400

This algorithm allows to convert time_t into UTC YYYY-MM-DD hh:mm:ss
without any additional information (leap second table), therefore
time_t is equivalent to a UTC time and certainly not to a TAI time.
To convert time_t into TAI, you need a leap second table, which
practically no system on this planet has (systems operated by members
of the tz mailing list excluded of course ;-).

> > TAI is only of concern in very special
> > purpose systems such as navigation and astronomical/geological observations.
> 
> Nonsense. One of the most basic code optimization techniques is to try
> several code alternatives on an unloaded system and time each one to see
> what's fastest. Many packages do this automatically during installation.
> What happens if someone installs such a package during a leap second?

Ok, slowly I understand fully your confusion. You should more carefully
differentiate between TAI and "some monotonic leap-second free
second count". These two are by no means the same. A monotonic second
count is trivial to implement. TAI is difficult to implement, because
to get TAI from the easily available UTC time, you need an up-to-date
leapsecond table.

I guess, what you really want is something like CLOCK_MONOTONIC as specified
in one of the more recent POSIX drafts (see current discussion in
comp.std.unix) and *not* a TAI clock. These are two very different functions.
POSIX's CLOCK_MONOTONIC (previously called CLOCK_FUNDAMENTAL) is
guaranteed to have no jumps and to be available right after system
startup. CLOCK_TAI is guaranteed to represent TAI within some reasonable
absolute accuracy (say 100 ms).

> Saying ``well, they should use RDTSC or gethrtime() or CLOCK_RIGHT'' is
> missing the point. They _don't_.

Bad training of software engineers leads to bad products. So what?

> Telling all of them to change, for the
> sake of a minor simplification in xntpd, is poor engineering.

Who says that the gettimeofday() or the CLOCK_REALTIME clock should
follow precisely UTC?

I fully favour to add to POSIX a CLOCK_UTC that represents leap seconds
by counting in tv_nsec from 1_000_000_000 to 1_999_999_999 while
keeping the code for 23:59:59Z in tv_sec. CLOCK_MONOTONIC will just
have a value that is one higher than the value it had a second ago
and nobody guarantees *anything* else about CLOCK_MONOTONIC. It can typically
be a second counter since the last boot. It has nothing to do with TAI.
For CLOCK_MONOTONIC (and the equivalent gettimeofday) we have
unfortunatelly not any definition of what their value near a leap second
should be. A reasonable hack is for instance what electricity companies do
after leap seconds. They reduce the frequency from (say) 60 Hz to 59 Hz
for one minute, and this way, all UTC clocks that get their reference
frequency from the power network have followed smoothly with
their phase the UTC timescale. Many Unix systems have an adjtime()
call that performs phase adjustments to the kernel clock smoothly
by reducing or increasing the clock's reference frequency by 1%
until the phases match again. If you reduce the allowed skew to
500 pmm (a reasonable upper limit for the worst crystal you will find
in not completely broken computer clock circuits), then you will
need 2000 seconds to get synchronization with UTC back.

> > Attosecond timescales are practically useless for the forseeable future.
> 
> Nanosecond timescales are woefully inadequate for certain applications.

They are a nice lower limit for a range of useful resolutions and they
are convenient to implement on 32-bit machines.

> Anyway, you should learn to read more carefully; /etc/leapsecs.dat uses
> TAI64, which is an 8-byte scale providing 1-second precision.

You should learn to read more carefully: My posting was carefully
written not to contain any references to /etc/leapsecs.dat. I was
generally discussing your Web page that as I understood it propagates
to use TAI as a generally preferable integer timestamping scale (such as
time_t), which I am convinced is a fatally bad engineering decision
(except in atomic clock driven navigation systems).

May be we are in violent agreement and are actually arguing in the
same direction and you just used TAI as a bad expression for "rate
monotonic clock", but if your vision really is to implement a kernel
clock in a way that allows to convert to/from TAI (or GPS or ET) without
a leap second table, then I feel that this is not a good design decision
for the reasons pointed out above.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>