Leap second to be added on December 31st 2016

Solution Verified - Updated -


Red Hat Enterprise Linux, any version


  • A positive leap second will be introduced on 31st of December, 2016. Will the system handle the leap second automatically ?
  • If the system is not using an NTP server for synchronization, is there any action required to handle the leap second?
  • Will the leap second be inserted automatically?


To have the system properly handle the leap second, the system needs either to use time synchronization service like NTP or PTP, or have the tzdata package updated to the version which includes the change. For more information about the leap second handling, see this featured knowledgebase article:
Resolve Leap Second Issues in Red Hat Enterprise Linux


  • Systems that synchronize their clock via NTP will have their clock stepped back by one second for the leap event. If you would like to test your systems to see this and how your applications/servers react, refer to this methodology: Red Hat Lab: Leap Second Issue Detector. If you would prefer to have NTP slew instead of step the time please refer to this document: Can I run NTP in slewmode?. This can help avoid issues such as Chronyd crashes when performing server leap smear.

  • By default, Linux systems not using NTP or PTP to synchronize their timekeeping will NOT correct for leap seconds, and the time reported by these systems will have a one-second difference relative to UTC after the leap second correction. You should reset the clock manually after leap seconds occur.

  • You can also configure these systems to report time corrected for leap seconds by updating the tzdata package to the latest version available, copying the appropriate file from the /usr/share/zoneinfo/right directory hierarchy to /etc/localtime. See How to change the system time zone for more information. The files in /usr/share/zoneinfo/right contain local time information corrected for all leap seconds that have occurred since the beginning of the Epoch on 1970-01-01 00:00:00 UTC. System time will jump ahead by 26 seconds when the timezone is changed. For more information, refer the article on tzdata and the root cause section "A background for TAI and UTC time scales".

    tzdata package: Apply the updated tzdata package errata RHBA-2016:2660-1 which adds the additional leap second on 2016-12-31 23:59:60 UTC

  • The other time zone files in /usr/share/zoneinfo do NOT have leap second corrections added.

  • If running an older RHEL 6 kernel version prior to 6.4, also review High CPU usage after inserting leap second.

  • If running an older RHEL 7 kernel version prior to December 6, 2016, also review Hrtimers may expire early when a leap second is inserted.

Root Cause

A leap second is a one-second adjustment which is applied to the Coordinated Universal Time (UTC) in order to keep its time of day close to the mean solar time. Leap seconds are added to our clocks (also referred to as "wall clock") to compensate for the Earth's slowing rotation.

A positive leap second is inserted between second 23:59:59 of the last day of June or December, and second 00:00:00 of the following date, once the need is indicated. This extra second is displayed on UTC clocks as 23:59:60.

Full announcement can be found on the following IERS datacenter page:
International Earth Rotation And Reference Systems Service (IERS)

Diagnostic Steps

  $ rpm -q tzdata
  $ zdump -v right/America/Los_Angeles | grep Sat.Dec.31.*2016
// no output yet

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


when this solution will be available so that i can update my Operating system.

At the moment, we do not have an ETA. Updated tzdata package will be provided well before Dec 31 2016. Please contact Red Hat Technical support and file a service request so that we can keep you updated with the latest developments

Leap second to be added on December 31st 2016 https://access.redhat.com/solutions/2441291

Resolve Leap Second Issues in Red Hat Enterprise Linux https://access.redhat.com/articles/15145

Solution released now

Leap second to be added on December 31st 2016 https://access.redhat.com/solutions/2441291

Resolve Leap Second Issues in Red Hat Enterprise Linux https://access.redhat.com/articles/15145

Sorry all too vague, almost like a "Chicken Little" type story. You need to provide credible statistical evidence of the probability of a Linux Kernel panic. Otherwise I might as well install a Microsoft Server OS. Happy to punt the probability of a Linux Kernel Panic is LOW, and that powering back on the server is a viable option.

This "statistical probability" will depend on the exact kernel version you are using on a system, and if then that kernel is affected by more than one issue which could lead to a panic, these would need to be combined.

So the first step for this would be to find out which issues could affect your kernel, for example after working through https://access.redhat.com/articles/15145. For some of these issues also workarounds without service downtime exist, for example the issue described here which can affect rhel7. For looking into a specific environment, a case with the Red Hat Support makes sense.