[LEAPSECS] Time math libraries, UTC to TAI

[Joseph Gwinn]

On Sun, 25 Dec 2016 00:11:18 -0500, John Sauter wrote:
> 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.

Many but not all people set their clocks to UTC.  See my item 3 above.

Probably the majority of computer users never heard of UTC.

 
> 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. 

Yes, that is a major goal.  Isolated means just that.  Think of a 
computer system at the bottom of a mine, or in a submarine.  Most such 
computers do not need to know UTC - local time is adequate.
 

>  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.  

In many systems, the GPS signal is simply not available, so a GPS 
receiver would be useless.  

And, as you mention, many sensors don't need to know UTC (or TAI or 
anything else) - local system time is adequate.  Time since last 
boot-up is very common in such applications - see section 4 above.


>   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.

Systems that need to track the Sun this will provide GPS or the like, 
to be able to perform their mission.  It does not follow that all 
systems have any need of astronomical data.  Usually, self-consistency 
and stability are the big requirements.

 
> 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.  

Depends on application.  Not all will display UTC. In many radar 
systems, the GPS receiver is instead configured to emit GPS System 
Time, not UTC, to avoid leap seconds.  See section 3 above.

Also note that many large radar systems have built-in simulators, used 
for system integration during development and for training thereafter.  
Such simulators need to be able to work using system time that is not 
the present, say to rerun recorded observations or to simulate future 
or past scenarios.  In both cases, the GPS receiver does not know the 
correct leap second offset to use.  The usual solution is an 
application-provided table all past leap seconds, plus the next leap 
second (if known).  The table is updated manually.


>  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?

Yes, sections 3 (modern) and 4 (historical, but many still in use) do 
describe different 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>

I had read this in October 2016, and reread it yesterday.  It does not 
solve the problem of isolated systems with local clocks, systems with 
no access to the sky.


> 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.

We get a 1PPS pulse train from GPS receivers, and also from Cesium 
clocks.  Cesium works better in isolated systems.

As others have mentioned, there is a vast existing base for POSIX time, 
so there is zero chance that time-t will become UTC.  Unless the leap 
seconds are elided from UTC, as was proposed and shelved at the ITU.

Understand that by policy, POSIX only codifies existing practice, so 
the usual path is that something non-standard is added by various 
vendors and over time becomes widely used, often in a flock of similar 
forms, some more widely supported than others.  Then the POSIX WG comes 
along and codifies the common part of the various forms, usually 
weighted by market prevalence.

A more likely scenario is thus to define a new kind of Named Clock in 
POSIX, and wait to see if the world uses it.  If yes, eventually it 
will become part of the standard, and the other clocks will drift into 
obscurity.  Understand that this process is glacial.

Joe Gwinn