The BBC reports:

An extra second will be added to the world's clocks on New Year's Eve in order to stay in sync with the Earth's rotation.

Does this mean that I have to do anything so that my Ubuntu machine keeps in time with this or will it automatically adjust itself to not be a second off?


If your Ubuntu machine listens to NTP and synchronizes time with the Internet, the system will automatically adjust itself for the difference in time.

While your computer might not necessarily be aware of the fact that a leap second happened, it will catch and record the event as NTP servers push the change throughout the internet.

If you don't feel like the extra second is being added, you can force an update using the following command:

sudo ntpdate -s time.nist.gov

If you are not in the US, replace time.nist.gov with the appropriate server as listed on this site. For the UK specifically, see this page for a list of valid servers.

Alternatively, if you're on a modern version of Ubuntu, there's a builtin utility called timedatectl. By default, this runs once automatically on startup. Therefore, a quick reboot can force a sync if necessary.

  • 1
    In the U.K., using time.nist.gov still works. Ubuntu adjusts what it reports for my timezone. I assume the same is true for all time zones – Tim Jan 1 '17 at 13:59
  • 2
    @Tim Yes, but synching with a server in the US has higher latency = higher error rate... so it works, but the end result is less precise than with using a closer server. – Bakuriu Jan 1 '17 at 15:19
  • 1
    Try pool.ntp.org instead; this should always pick up something relatively close to you. – Michael Hampton Jan 1 '17 at 18:09
  • 3
    This answer is problematic. 1.) If you're very unlucky, none of the time servers you'll using will handle the leap second correctly. It's unlikely, but possible. 2.) If ntpd is running, running ntpdate simultaneously will confuse it. Better to stop it first. Better yet, don't run ntpdate at all. 3.) The NIST time servers don't need extra traffic from Stack Exchange; ntp.ubuntu.com or pool.ntp.org would be better. 4.) The UK actually uses uk.pool.ntp.org, but pool.ntp.org will perform geolocation anyway. – Matt Nordhoff Jan 1 '17 at 22:37
  • I forgot one. 5.) If you're running ntpdate against random time servers, and you're very unlucky again, you'll use one that also failed to handle the leap second correctly! The NTP Pool deactivates such servers quickly, but not instantly. And prominent government servers aren't any better. (Though i think the NIST ones were this time.) – Matt Nordhoff Jan 1 '17 at 22:41

Leap seconds are handled automatically by the Linux kernel, no reboot or NTP sync is required to keep actual time. If you look in your system log, you will see something similar to

[263284.397894] Clock: inserting leap second 23:59:60 UTC

Since 23:59:60 is not a valid Linux time, your clock will reach 00:00:00, then step back to 23:59:59. Any objects created during that second (like files) can be dated inconsistently.

As far as Linux time (as opposed to real time) is concerned, leap seconds don't exist:

# date -d "2016-12-31 23:59:59" +%s
# date -d "2017-01-01 00:00:00" +%s
  • 2
    My logs do appear to confirm this answer. I recently ran dmesg | grep 'leap second' on my main 16.04 machine and it showed [1153894.866672] Clock: inserting leap second 23:59:60 UTC. This, just with different numbers at the beginning, was also shown on my minimal 16.04 VM, installed from mini.iso, that I use for testing. That minimal system does not have ntpd running, nor does it have either of the ntp or openntpd packages installed. – Eliah Kagan Jan 1 '17 at 9:03
  • 2
    @EliahKagan Surely the kernel does not have a list of all future leap seconds hardcoded. The kernel has the logic to insert the leap second, but something must tell the kernel that a leap second is to be inserted. I don't know of anything other than NTP which can tell the kernel to insert a leap second. Notice that if the kernel has already been instructed to insert a leap second, then uninstalling NTP without rebooting will leave the kernel in a state where it will insert a leap second. – kasperd Jan 1 '17 at 13:25
  • 1
    @kasperd I agree with your general reasoning, but I don't think NTP has ever been installed in that system, which I set up just a few (though more than one) days earlier. Two possibilities come to my mind. This is a VMware virtual machine, and though I haven't installed any VMware drivers, I believe Ubuntu already has some. Might such a driver have found out about the leap second from the host machine? Aside from that, I expect NTP was involved during installation, though I'm not sure how that was made to work across reboots. I think mini.iso itself has NTP and that debian-installer uses it. – Eliah Kagan Jan 1 '17 at 14:26
  • 1
    @EliahKagan, I did not check, but the default ntp client may be chrony. – Carsten S Jan 2 '17 at 9:05
  • 2
    @CarstenS It turns out systemd-timesyncd(8) has been synchronizing my minimal system's clock. I hadn't thought of this, and found out by semi-accident: grep -RPis '(?<!mou)ntp' /var/log revealed these 14 syslog lines, showing time syncs from a host that happens to have ntp in its name. In hindsight, it makes sense that the mysterious service I never knew I had was part of systemd. (Btw, good point about chrony, which I hadn't checked for either; it's not installed, though.) – Eliah Kagan Jan 2 '17 at 16:09

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.