[LEAPSECS] Time math libraries, UTC to TAI

[Joseph Gwinn]

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


On Tue, 13 Dec 2016 10:50:53 -0500, John Sauter wrote:
> Eric,
> 
> I attach a set of time manipulation subroutines I have been working on.
>  You can extract the sources from the PDF file using okular.
> 
> These subroutines manipulate time expressed as UTC coded in a tm
> structure.  They extract the current time and allow addition and
> subtraction of years, months, days, hours, minutes and seconds.  They
> also handle local time and deal properly with leap seconds.  Details
> are in the PDF file.
> 
> I am planning to update the software to include the latest research on
> historical values of Delta T, but this version will work until I can
> get to that.  I would appreciate any feedback you might have.
> 
> Since these subroutines handle leap seconds while expressing time using
> UTC, you can use UTC rather than TAI as your time scale.
> 
> You said you are capturing meta-data about the devices from which you
> capture time.  I feel that this is absolutely required, and I
> congratulate you for doing this.
>     John Sauter (JOhn_Sauter at systemeyescomputerstore.com)
> -- 
> PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs