[time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?

[jimlux]

On 8/8/19 2:51 AM, Tim Dunker wrote:
> Dear Ralph
> 
> I keep all our GNU/Linux machines on UTC (i.e., <<Etc/UTC>>). Our
> timezone is off by one or two hours, but the actual offset does not
> matter to me. What matters to me is to have all systems using the same
> timezone, and for our purposes, nobody cares about our local time.
> 
>>> Can the same thing be done in practice with TAI?
> 
> Yes, I guess so, but you have to go to much greater lengths to get it to
> work. Red Hat has a nice article [1] on their website on leap second
> handling in the kernel and clients like ntpd and chronyd. You have
> probably also read a thread on superuser.com [2], where ntpd and chronyd
> problems are discussed.
> 
>>> TAI would probably be the more logical way to store and do
> calculations with time, only including leap seconds when formatting time
> for human consumption. Or am I wrong in this?
> 
> Maybe I am just dumb, but I personally see no advantage of doing this
> extra work. Is TAI a logical choice while UTC is not? Hm. We know when a
> leap second is inserted (or removed, even though it has yet to happen),
> so for all human-readable stuff (log files, data analysis, ...), I am
> happy to have everything on UTC.
> 
> That being said, TAI is very nice if you acquire data continuously and
> leap second handling is not ideal on the instrument in question. But as
> long as you do not do that, it seems easier to me to go the other way
> around: keep everything on UTC, but convert to TAI when necessary.
> 

If you're setting up events that have to occur at some time in the 
future, relative to a time now, TAI is your friend, because you don't 
have to worry about crossing a leapsecond boundary.

If it's June 29th, and I want to schedule an event to occur on July 3rd, 
exactly 400,000 seconds from now, it's nice to not have to worry about 
whether anyone is counting leap seconds.

Likewise, if you are processing a stream of data, it's nice to be able 
to just subtract time1 from time2, and not have to worry if the 
timedelta needs an adjustment.

Historically, in the space business, spacecraft measured their own time 
in terms of clock ticks, and you'd uplink commands in terms of clock 
ticks, for that spacecraft. Some folks on the ground keep track of time 
correlation, and adjusting for tick rates, earth received time, etc. so 
that data collections, trajectory correction burns, etc. all happen at 
the right time.

Fine if your one spacecraft is Cassini and you have a team of dozens to 
manage it. Or even a Mars rover and a Mars Orbiter that need to 
communicate with each other - there's folks on the ground who can figure 
it out, and you can manually avoid doing transfers or activities across 
a leap second. We actually did this with ops on SCaN Testbed on ISS - we 
shut down before midnight UTC, waited until around 00:30 UTC, just to 
make sure the leap second had propagated around, including any 
"smearing", and started ops back up to finish the experiment.


Not so fine if you have 100 spacecraft, each with different clocks, 
communication schedules, etc.

Do the calculations and data storage/retrieval in a monotonically 
increasing, constant rate (or at least continuous rate for the first 
couple derivatives) time scale, and convert to whatever you want for 
human interpretation.  This is especially true if there's more than one 
system involved, because then you don't have to worry if the two systems 
agree on their interpretations.