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/right timezone files need to be updated?
  • TAI is monotonic, so no seconds are inserted or removed. So you cannot see a time like 23:59:60.
    – Huygens
    Jun 19, 2017 at 10:58

2 Answers 2


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.


Timezone files may need to be updated. You can test it by running a command to see the transitions in the installed timezone file. The following example contains a leap-second transition.

$ zdump -c 2017,2018 -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime Sat Dec 31 23:59:60 2016 UT = Sun Jan 1 01:59:60 2017 EET isdst=0 gmtoff=7200 /etc/localtime Sun Jan 1 00:00:00 2017 UT = Sun Jan 1 02:00:00 2017 EET isdst=0 gmtoff=7200 /etc/localtime Sun Mar 26 00:59:59 2017 UT = Sun Mar 26 02:59:59 2017 EET isdst=0 gmtoff=7200 /etc/localtime Sun Mar 26 01:00:00 2017 UT = Sun Mar 26 04:00:00 2017 EEST isdst=1 gmtoff=10800 /etc/localtime Sun Oct 29 00:59:59 2017 UT = Sun Oct 29 03:59:59 2017 EEST isdst=1 gmtoff=10800 /etc/localtime Sun Oct 29 01:00:00 2017 UT = Sun Oct 29 03:00:00 2017 EET isdst=0 gmtoff=7200 /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL

If the timezone file needs updating and if no leap-second (/right) timezone file is provided by your operating system distribution, you can set up the timezone file as follows.

  • fetch the timezone distribution from https://www.iana.org/time-zones,
  • configure and install, and
  • set up the correct zone file (which also includes leap second info) with a command such as the following

sudo cptzdir/etc/zoneinfo-leaps/your-timezone /etc/localtime

To set the time from an NTP server you can configure and install rdate (openrdate) and then run a command such as sudo rdate -s -c -n 0.gentoo.pool.ntp.org.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .