43

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?

Improve this question
2

2 Answers 2

Reset to default
34

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 pool.ntp.org

This will automatically perform geo-location to give you a nearby server (reducing the latency error) and Ubuntu will adjust for your timezone (so if the server is in a different timezone, it's still all okay). Alternatively, you can use ntp.ubuntu.com.

Note that if you're very unlucky, none of the time servers you're using will handle the leap second correctly. It's unlikely, but possible. Checking manually against a known good source (analogue radio, possibly time.is) is advised.

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

Improve this answer
5
  • 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, 2017 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, 2017 at 15:19
  • 1
    Try pool.ntp.org instead; this should always pick up something relatively close to you.
    – Michael Hampton
    Jan 1, 2017 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, 2017 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, 2017 at 22:41
17

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
1483225199
# date -d "2017-01-01 00:00:00" +%s
1483225200
Improve this answer
12
  • 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, 2017 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, 2017 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, 2017 at 14:26
  • 1
    @EliahKagan, I did not check, but the default ntp client may be chrony.
    – Carsten S
    Jan 2, 2017 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, 2017 at 16:09

You must log in to answer this question.