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

[Tim Dunker]

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.


Cheers
Tim

[1] https://access.redhat.com/articles/15145
[2]
https://superuser.com/questions/1156693/is-there-a-way-of-getting-correct-clock-tai-on-linux

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20190808/1e36a003/attachment.sig>