How do I configure a Unix system to run on TAI time?
I want to configure a Unix system to run on International Atomic Time (TAI) in order to be able to see the year-end leap second properly reported as 2016-12-31 23:59:60. I know this will cause the system's timestamps to be incompatible with POSIX ones, but I'm doing this as an experiment. I have already copied the timezone file from /usr/share/zoneinfo/right/ to /etc/localtime. These are my questions.
- How can I accurately set the system's time? I understand that it must be set to TAI seconds, rather than UTC seconds. Is it possible to do this via NTP? Currently, the system displays the time 36 seconds off from the correct one.
- Will the displayed time continue to be correct after 2017-02-01? Do the
zoneinfo/righttimezone files need to be updated?
First, the notion that the clock on a computer system must be provided TAI or UTC is not strictly accurate. I can get and set the time with time zones, for example GNU coreutils date command is very flexible. On a system set to right/UTC (more on this later):
# date -s "Tue Dec 27 08:16:53 CST 2016"
Tue Dec 27 14:16:53 UTC 2016
See ESR's essay Time, Clock, and Calendar Programming In C for the actual data structures involved, and some good references.
You still may configure ntp, ptp, or issue well-timed date or chronyc settime command as usual.
However, you need to understand the TAI - UTC offset and what your source time is. NTP time is standardly UTC, so just setting a "right" zone on a UTC synced system will be off by TAI - 10 - UTC, which is currently 26.
Instead, some NTP servers can provide GPS or TAI. This plus some leap second hacks will get rid of the leap second error corrected by the kernel or user land time sync. See: "right" tz database (zoneinfo) files and GPS-based NTP
Beware that 86401 second days is nonstandard and against what POSIX supposedly requires. If setting up NTP servers that do this, they cannot provide time for other systems. It can also result in strange behaviors from applications that depended on a particularly formatted time.
TZ data will need to updated, twice a year will catch leap seconds. If you patch leap seconds for this reason you will need to do it again. (Very likely you already need to update other software more often than this for various reasons.) There will be additional leap seconds, the Earth's rotation change is a physical necessity. There also is a political necessity of the likely time zone and daylight savings time changes for… less technical reasons.
Good timing, as the next leap second is 2016 December 31, 23h 59m 60s.
Red Hat published a good summary of ways to deal with it on Linux if one is using UTC. Note that many sites repeat, smear, or let NTP fix the second of error without needing to show the 61st second.
Resolve Leap Second Issues in Red Hat Enterprise Linux
This all seems like a lot of work to me. I'd rather not see the 61st second, if I could let NTP or the kernel deal with it, via the methods the Red Hat describes.