[LEAPSECS] Time math libraries, UTC to TAI

[John Sauter]

On Mon, 2016-12-26 at 11:57 -0500, Joseph Gwinn wrote:
> 
> > 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.

Sorry, that was an over-simplification on my part.  I should have said
"almost everyone" since you described a case in which the time was
deliberately set to a non-UTC time scale.  In addition, I should have
said that almost everyone sets their clock to a time "based on" UTC,
specifically their local time.  They also set their computer's time
zone variable to their local time zone.

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

Perhaps I misunderstood.  I thought you said that the internal time was
converted to UTC for display.  Perhaps some, but not all, radars do
that?

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

That sounds like a fine solution.  It would be nice if the table were
maintained by the group of people who needed it, so that everyone
wouldn't have to update his own table.

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

I agree.  I was suggesting the NISTDC as a robust and accurate
replacement for a GPS receiver.

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

I agree that POSIX time_t will not become UTC.  That is why I advocate
not using it.

> 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


I think a new named clock would be a fine idea.  Asking for the current
time using the new clock could return time_t just like CLOCK_REALTIME,
but return nanoseconds + 1e9 during a leap second.  That could be
decoded into a tm structure and also used in file systems for access
time, modification time and creation time.

Yes, the process is glacial, but slow progress is better than no
progress.
    John Sauter (John_Sauter at systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
-------------- 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/20161227/29e30983/attachment.pgp>