[LEAPSECS] Time math libraries, UTC to TAI

[John Sauter]

Joseph Gwinn (joegwinn at comcast.net) wrote:

John,

I've read your paper "Avoid Using POSIX time_t for Telling Time" 
(2016-12-08), and have some general comments:

1.  Despite the resemblance to UTC, POSIX time is by intent *not* UTC,
so all the observations that actual days can differ from 86,400 seconds
and so on are correct, but beside the point - there are no leap seconds
in POSIX Time.  The reason is that POSIX Time must work in isolated
systems, ones having no access to leap second data.  This issue comes
up from time to time, and there are a number of archived email fights
on the subject, laying out the whole issue.  POSIX Time is its own
timescale, the details of which flow from the objectives and
requirements of POSIX operating systems.  While the POSIX Time Epoch is
defined in terms of UTC (originally GMT), the progression rule is an
approximation of atomic time - it just marches along, counting out
seconds without reference to astronomy.

2.  The new and modern timescale that most resembles POSIX Time is
TAI.  TAI was traditionally a paper clock, but the rise of IEEE 1588
Precision Time Protocol (PTP) has caused TAI to be implemented in
practical time generation and distribution systems.  Specifically, one
can now buy GPS receivers that can be configured to publish GPS System
Time, UTC, and now TAI.  This makes it simple and direct to use TAI
where one would have used UTC.  Keeping in step with civil time is then
performed only at interfaces where UTC or local civil time is required,
the core of the system (with millions of lines of code) being
blissfully unaware of leap seconds.

3.  Over my career building large radar systems, the typical setup is
that the radar runs on GPS System Time distributed as if it were UTC.  
This is achieved by setting the GPS receiver to emit GPS System Time,
and letting NTP think that this is UTC.  Actually, NTP botches leap
seconds - a negative leap would cause the last second to be re-run, and
a positive leap causes a time wobble.  The radar software does notice
these deviations from uniformity.  The bump that a leap second would
cause is intolerable in most such systems, so leap seconds are banned
from the core.  The displays and interfaces to external systems do any
necessary conversion to and from UTC or local civil time.

4.  FYI, typical radar software internally uses an integer count of
clock ticks since their Epoch, which varies.  The use of integer counts
allows mathematically exact time arithmetic to be done efficiently.  In
these systems, time is a form of data, and not the clock on the wall.  
Think tracking of things flying by.  One system from decades ago
counted milliseconds "since Christ died" (well, the start of the
Gregorian Calendar) in a 48-bit integer.  More recent systems count
nanoseconds in a 64-bit integer.  Monotonic Time in POSIX is modeled on
these timescales.

Joe

John Sauter (John_Sauter at systemeyescomputerstore.com) responded:

Thank you for your comments, Joe.

I agree that POSIX defines its own time scale for time_t, but that is
not how it is being used.  Everyone sets their computer’s clock to UTC,
no matter what the standard says, and no matter how many seconds have
passed since 1970-01-01T00:00:00Z.

I have long heard that a design goal of POSIX was that it be functional
in an isolated system, but I am not sure what that really means.  A
totally isolated computer might as well be switched off, since nothing
communicates with it.  That isn’t a reasonable meaning for “isolated”
in this context, so what, really, is an isolated computer?  Perhaps it
means a computer with a very limited set of sensors for input, and a
very limited set of effectors for output.  If that is the case, surely
one of the sensors can be a GPS receiver so the computer can keep its
clock accurate.  If not, then perhaps the computer’s clock doesn’t need
to be accurate, and therefore has no need to update its leap second
table.  However, if a computer is going to track the Sun across the
sky, it will need access to astronomical data, because the position of
the Sun in the sky cannot be predicted to within a second five years in
the future.  Realistically, an “isolated” computer needs whatever
inputs are required for it to do its job, and that might include the
time.

The TAI time scale was synchronized to UTC when it was created in 1958,
and has since not counted leap seconds.  Similarly, the Navstar GPS
system was synchronized to UTC in 1980 and has since not counted leap
seconds, making GPS time a fixed offset from TAI.  GPS receivers, like
your radar systems, convert to UTC when displaying time.  The Navstar
GPS satellites are informed of an upcoming leap second, and pass that
down to the receivers, so they can display UTC correctly.  I suppose
your radar systems do the same.  Your description of a typical radar
system in part 4 is even simpler: just a count of seconds since its
Epoch, converted to UTC for display.  I am not clear from your
description how the transition is made from NTP distributing GPS time
as though it were UTC, to an internal seconds counter.  Were you
describing different radar systems?

You may not have seen this reference from an October posting in the
leap seconds mailing list:

http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf

The NIST Disciplined Clock outputs one pulse per second with
astonishing accuracy.  I dare say it would be good enough to provide
clock to a radar facility.  The pulses are nameless, and hence do not
suffer from leap seconds.
    John Sauter 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20161225/ba86d9f7/attachment.pgp>