Leap Second queries related to tzdata

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • NTP,tzdata
  • Leap Second, June 30, 2015

Issue

  • As per the Red Hat Leap Second Article, I need to update the tzdata package. Do I need to take any further actions after updating tzdata?

  • If my RHEL host is a NTP client, do I need to update the tzdata package? What if I do not update the tzdata package OR I just only update the ntp package and the kernel as per the Red Hat Leap Second Article?

  • Is it necessary to have the latest tzdata package for avoiding any issues during the addition of leap second?

  • For my RHEL host which is not a NTP client what will happen if I do not update the tzdata package?

  • What are the TAI and the UTC time scales? Do I need to consider these time scales while upgrading the tzdata package?

  • For my RHEL host which is not a NTP client and using the TAI timescale, should I be upgrading the tzdata package?

Resolution

  • As per the Red Hat Leap Second Article, the inference is that you need not update the tzdata package if the RHEL host is a NTP client. However, it is upto the discretion of the user/customer to consider upgrading tzdata as per the recommendations which one may observe after executing the leap_vulnerability.sh script on the RHEL server as per the Leap Second Issue Detector.

  • Is it necessary to have the latest tzdata package if my RHEL host is a NTP client?
    The answer is no. Upgrading NTP to the suitable or in some cases to the latest version and having the recommended kernel version as per the Red Hat Leap Second Article is just enough.

  • For my RHEL host which is not a NTP client what will happen if I do not update the tzdata package?
    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. One should reset the clock manually after leap second occurrence.

  • For my RHEL host which is not a NTP client and using the TAI timescale, should I be upgrading the tzdata package?
    If the non-NTP RHEL host is following the TAI timescale then one can also configure such non-NTP RHEL 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, and resetting the clock to the correct local time by executing the tzdata-update command. 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. The other time zone files in /usr/share/zoneinfo do not have leap second corrections added. Below is just a proof :-

[root@server ~]# file /usr/share/zoneinfo/Asia/Kolkata 
/usr/share/zoneinfo/Asia/Kolkata: timezone data, version 2, 4 gmt time flags, 4 std time flags, no leap seconds, 4 transition times, 4 abbreviation chars

[root@server ~]# file /usr/share/zoneinfo/right/Asia/Kolkata 
/usr/share/zoneinfo/right/Asia/Kolkata: timezone data, version 2, 4 gmt time flags, 4 std time flags, 26 leap seconds, 4 transition times, 4 abbreviation chars

  • For my RHEL host which is not a NTP client and using the UTC timescale (the default one), should I be upgrading the tzdata package?
    The answer is no. It is not mandatory as the tzdata upgrade is meant for applications depending upon the TAI timescale. In this case, one may adjust the time on such a host manually. With NTP the system clock is always in UTC. If you are using a right/* timezone (which is based on the assumption that the system clock is in TAI-10 instead of UTC) when the system clock is synchronized by NTP, you will see local time (as printed by date command for example) off by 25 seconds or after June 30,23:59:59 UTC by 26 seconds.

  • So what will happen if my host was not using TAI time scale but I still upgrade the tzdata package on my RHEL host which was not using NTP? Will the applications be impacted?
    If the applications on the host are following the UTC time scale then following the upgrade it is very likely that they would be impacted. If the applications were designed for/running as per the UTC time scale, then one should not upgrade tzdata and further execute tzdata-update so that the usr/share/zoneinfo/right/../.. files take into effect.

  • What further actions we need to take after updating the tzdata package considering my RHEL host is not a NTP client and using the TAI time scale? Do I need to restart my RHEL server after tzdata package upgrade?
    Its important to note that the action of updating the tzdata package alone is not sufficient. After the tzdata package is updated, one need not restart the server however one does need to carry out the below action for the new tzdata package to take into effect:-

  1. Copy the appropriate file from the /usr/share/zoneinfo/right directory to /etc/localtime. 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. Execute the below command :-
cp /usr/share/zoneinfo/right/Asia/kolkata /etc/localtime

In the /etc/sysconfig/clock, one should also verify if the below directive is present as shown below:-

ZONE="right/Asia/Kolkata"

One may choose any other suitable file as applicable instead of the /usr/share/zoneinfo/right/Asia/kolkata. In order to determine what file one should choose, look at the ZONE directive in the /etc/sysconfig/clock file.

  1. Execute the below command :-
tzdata-update

Now the leap second corrections are included. You may further validate it by executing the below command :-

[root@server ~]# zdump -v /usr/share/zoneinfo/right/Asia/Kolkata | grep :60 | tail -1
/usr/share/zoneinfo/right/Asia/Kolkata  Tue Jun 30 23:59:60 2015 UTC = Wed Jul  1 05:29:60 2015 IST isdst=0 gmtoff=19800
  • If my RHEL host is not a NTP client, do I need to update the tzdata package? What if I do not update the tzdata package OR I just only update the ntp package?
    Deciding for situations as these, one needs to understand/be aware if the applications on non-NTP RHEL hosts are expecting UTC time scale or the TAI time scale.
    Please check the file /etc/sysconfig/clock contents to determine if you are using the UTC or the TAI timescale. If the ZONE directive in this file looks like as shown below :-
ZONE="right/Asia/Kolkata"

then it means that the server is following the TAI timescale and one needs to update the tzdata package.

Alternatively, if the user has copied the /usr/share/zoneinfo/right/Asia/Kolkata to /etc/localtime and executed the tzdata-update, even if the ZONE directive is as below 

ZONE="/Asia/Kolkata"

then one needs to upgrade the tzdata package. One may also validate the same by reviewing the output of the below command :-

file /etc/localtime

Please be advised that any application that expects the time to be in UTC will have issues if a right/ timezone is used.*

Note :- Red Hat does not recommend running without a source of time synchronization enabled as there is no guarantee that systems will remain in sync with each other. Time drift may occur on each system as determined by its clock source. The decision to run without NTP/PTP/Chrony will need to be made on a per-system or per-cluster basis with the understanding that time drift may occur.

Root Cause

A background for TAI and UTC time scales
TAI has been exactly 25 seconds ahead of UTC after 2012 leap second event besides the initial 10 seconds difference between them when UTC came into being in 1972. This can break any application or protocol that uses the system time directly and expects it to be in UTC.

International Atomic Time (TAI, from the French name Temps Atomique International) is a high-precision atomic coordinate time standard based on the notional passage of proper time on Earth's geoid.

TAI = International Atomic Time (Temps Atomique International = TAI) is defined as the weighted average of the time kept by about 200 atomic clocks in over 50 national laboratories worldwide.TAI-UT1 was approximately 0 on 1958 Jan 1.

UTC = Coordinated Universal Time. Differs from TAI by an integral number of seconds. When needed, leap seconds are introduced in UTC to keep the difference between UTC and UT less than 0.9 s.UTC was introduced in 1972.

In 1972, the present definition of time keeping was adopted that include the insertion of leap second so that the broadcast UTC seconds could be made exactly equal to the standard SI second, while still maintaining the UTC time of day and changes of UTC date synchronized with those of UT1. By then, the UTC clock was already 10 seconds behind TAI, which had been synchronized with UT1 in 1958, but had been counting true SI seconds since then. After 1972, both clocks have been ticking in SI seconds, so the difference between their readouts at any time is 10 seconds plus the total number of leap seconds that have been applied to UTC (35 seconds in July 2012). After 23:59:59 UTC , June 30,2015 the difference between UTC and TAI timescales would be 36 seconds.

SBR
Product(s)
Components
Category
Tags

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.