Zero-Touch Leap Second Maintenance with Openshift

Telecommunication networks rely heavily on protocols like Network Time Protocol (NTP) and Precision Time Protocol (PTP) to maintain accurate time across their infrastructure. From time to time a unique challenge arises with "leap seconds" – a one-second adjustment occasionally applied to Coordinated Universal Time (UTC) to reconcile atomic time (TAI) with Earth's irregular rotation.
Historically, managing these leap seconds, particularly in network environments disconnected from the internet, has been a significant burden. The International Earth Rotation and Reference Systems Service (IERS) announces leap second changes, and this information is typically distributed via a machine-readable file called leap-seconds.list. In isolated networks, this file requires manual updates, leading to considerable maintenance overhead and the potential for catastrophic errors if mishandled. Failures to account for leap seconds have, in the past, caused significant downtimes and incidents.

The Problem with Traditional Leap Second Handling

Consider the typical flow of leap second announcements:

1. IERS announces the adjustment date and direction on the Internet.
2. GPS satellites receive updates and begin broadcasting this leap event information.
3. Primary Reference Time Clocks (PRTCs) make this information available via their time reference output.
4. PTP Telecom Grandmasters (T-GMs), implementing the IEEE1588 PTP standard, announce the upcoming leap event 12 hours in advance, propagating this information through the downstream time distribution network to ensure correct clock adjustment at midnight in all connected nodes.

However, existing implementations face key challenges:

• The system clock of the T-GM itself and its update during a leap event are often not automatically handled.
• NTP servers in disconnected networks cannot automatically update the leap-seconds.list file without internet access.
• In modern virtualized or cloud environments where T-GMs coexist with other applications on the same node, a missed leap second adjustment can create time offsets between applications, leading to inconsistencies.

Introducing the Leap Manager: A Zero-Touch Solution

The solution addresses these problems by introducing the Leap Manager as an additional software block. The Leap Manager is initially built with a default leap-seconds.list file from IERS and then performs three functions during runtime:

1. Leap Announcement Extraction: The Leap Manager continuously monitors the PRTC Time Reference for notifications of upcoming leap seconds. This eliminates the reliance on external internet connectivity for updates.
2. Leap File Update: It detects any discrepancies between the existing leap-seconds.list file and the leap event announcements recovered from the PRTC Time Reference. Crucially, this function automatically updates the leap file's expiration and change times and provides cryptographic integrity protection for the updated file. This ensures the authenticity and reliability of the leap second information.
3. Leap File Publishing: The Leap Manager ensures that the updated leap file is readily available for read access to all authorized network functions. In OpenShift environments, this can be achieved by publishing the leap-seconds.list file as a Kubernetes resource, such as a ConfigMap, which pods can then mount as a file or access via the Kubernetes API.

For telecommunication OCP customers, this translates to tangible business value:

• Reduced maintenance costs: Automation of leap second updates drastically cuts down on manual effort and associated expenses.
• Minimized network downtimes: By ensuring accurate and consistent time synchronization, the risk of outages caused by time discrepancies is significantly reduced.
• Cost reduction through OCP-based implementations: Replacing dedicated hardware appliances with OCP-based solutions, enhanced by this zero-touch leap second handling, offers substantial cost savings.

In essence, the integration of this Leap Manager within a PTP Operator framework provides a robust, self-sustaining mechanism for managing leap seconds, ensuring uninterrupted and precise time synchronization.

Understand the leap data in PTP operator

PTP operator stores leap second information in a Configmap named leap-configmap in the openshift-ptp namespace.

[core@cnfdg3 ~]$ oc -n openshift-ptp get cm  leap-configmap -ojson | jq -r '.data."cnfdg3.ptp.eng.rdu2.dc.redhat.com"'
# Do not edit
# This file is generated automatically by linuxptp-daemon
#$  3676924800
#@  4291747200
2272060800     10    # 1 Jan 1972
2287785600     11    # 1 Jul 1972
2303683200     12    # 1 Jan 1973
2335219200     13    # 1 Jan 1974
2366755200     14    # 1 Jan 1975
2398291200     15    # 1 Jan 1976
2429913600     16    # 1 Jan 1977
2461449600     17    # 1 Jan 1978
2492985600     18    # 1 Jan 1979
2524521600     19    # 1 Jan 1980
2571782400     20    # 1 Jul 1981
2603318400     21    # 1 Jul 1982
2634854400     22    # 1 Jul 1983
2698012800     23    # 1 Jul 1985
2776982400     24    # 1 Jan 1988
2840140800     25    # 1 Jan 1990
2871676800     26    # 1 Jan 1991
2918937600     27    # 1 Jul 1992
2950473600     28    # 1 Jul 1993
2982009600     29    # 1 Jul 1994
3029443200     30    # 1 Jan 1996
3076704000     31    # 1 Jul 1997
3124137600     32    # 1 Jan 1999
3345062400     33    # 1 Jan 2006
3439756800     34    # 1 Jan 2009
3550089600     35    # 1 Jul 2012
3644697600     36    # 1 Jul 2015
3692217600     37    # 1 Jan 2017

#h  3ce176b7 325b0bdb 9802f120 38112b0c 6781420a

The timestamps are in the NTP format, i.e. number of seconds since January 1st 1900. Let’s verify the latest leap second update:

[core@cnfdg3 ~]$ python
Python 3.9.21 (main, Jun 27 2025, 00:00:00) 
[GCC 11.5.0 20240719 (Red Hat 11.5.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime(1900,1,1) + datetime.timedelta(seconds=3692217600)
datetime.datetime(2017, 1, 1, 0, 0)
>>> 

The file header contains two timestamps: the creation date and the expiration date:

>>> # created $  3676924800
>>> # expires @  4291747200
>>> datetime.datetime(1900,1,1) + datetime.timedelta(seconds=3676924800)
datetime.datetime(2016, 7, 8, 0, 0)
>>> datetime.datetime(1900,1,1) + datetime.timedelta(seconds=4291747200) 
datetime.datetime(2036, 1, 1, 0, 0)

Experiment 1: What happens when leap configmap is not present

Let’s delete the leap configmap and the linuxptp-daemon pod to imitate the initial state, and monitor the logs.

[core@cnfdg3 ~]$ oc -c linuxptp-daemon-container logs ds/linuxptp-daemon -f |grep Leap
I0831 16:36:52.440324 1965396 leap-file.go:198] Populate Leap data from file
I0831 16:36:52.445210 1965396 leap-file.go:235] Leap file expiration is set to 4291747200
I0831 16:36:52.445305 1965396 leap-file.go:241] starting Leap file manager
I0831 16:37:55.457075 1965396 leap-file.go:377] Leap indication: &{SrcOfCurrLs:2 CurrLs:18 SrcOfLsChange:2 LsChange:0 TimeToLsEvent:36228126 DateOfLsGpsWn:2441 DateOfLsGpsDn:7 Valid:3}
^C

The first three lines indicate that the leap-configmap is created from defaults and the leap file management is started. The last shows a leap second indication received from the GNSS module. Since no new leap information is indicated, the leap file remains unchanged.

Experiment 2: Leap information update

Let’s change the leap second file and make the leap manager to update it from the GNSS data. We want to remove the last line (3692217600 37 # 1 Jan 2017), which will set the leap seconds amount to 36, and then check that the Leap manager updates the configmap from the GNSS report.

[core@cnfdg3 ~]$ NODE_NAME=cnfdg3.ptp.eng.rdu2.dc.redhat.com
[core@cnfdg3 ~]$ RM_LINE_NUM=$(($(oc -n openshift-ptp get cm leap-configmap -ojson |jq -r '.data."'"$NODE_NAME"'"' |wc -l)-2))
[core@cnfdg3 ~]$ echo $RM_LINE_NUM
32
[core@cnfdg3 ~]$ NEW_CONTENT=$(oc -n openshift-ptp get cm leap-configmap -ojson |jq -r '.data."'"$NODE_NAME"'"' |sed -e "${RM_LINE_NUM}d")

[core@cnfdg3 ~]$ oc -n openshift-ptp create cm leap-configmap  --from-literal="$NODE_NAME"="$NEW_CONTENT" --dry-run=client -oyaml  |oc apply -f -
Warning: resource configmaps/leap-configmap is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by oc apply. oc apply should only be used on resources created declaratively by either oc create --save-config or oc apply. The missing annotation will be patched automatically.
configmap/leap-configmap configured

We patched the leap-configmap and removed the line indicating the latest number of leap seconds, making the leap data outdated.
Let's delete the linuxptp-daemon pod and wait for the leap manager to detect and correct the mismatch.

[core@cnfdg3 ~]$ oc delete $(oc get po -oname |grep daemon)
pod "linuxptp-daemon-2j9s8" deleted

[core@cnfdg3 ~]$ oc -c linuxptp-daemon-container logs ds/linuxptp-daemon -f |grep Leap
I0831 16:57:27.215096 1988494 leap-file.go:228] Populate Leap data from configmap
I0831 16:57:27.215222 1988494 leap-file.go:235] Leap file expiration is set to 4291747200
I0831 16:57:27.215323 1988494 leap-file.go:241] starting Leap file manager
I0831 16:58:25.227763 1988494 leap-file.go:377] Leap indication: &{SrcOfCurrLs:2 CurrLs:18 SrcOfLsChange:2 LsChange:0 TimeToLsEvent:36226888 DateOfLsGpsWn:2441 DateOfLsGpsDn:7 Valid:3}
I0831 16:58:25.227844 1988494 leap-file.go:400] Leap Seconds on file outdated: 36 on file, 18 + 19 + 0 in GNSS data

Let’s verify the leap-configmap is updated:

[core@cnfdg3 ~]$ oc -n openshift-ptp get cm  leap-configmap -ojson | jq -r '.data."cnfdg3.ptp.eng.rdu2.dc.redhat.com"'
# Do not edit
# This file is generated automatically by linuxptp-daemon
#$  3965649361
#@  4291747200
2272060800     10    # 1 Jan 1972
2287785600     11    # 1 Jul 1972
2303683200     12    # 1 Jan 1973
2335219200     13    # 1 Jan 1974
2366755200     14    # 1 Jan 1975
2398291200     15    # 1 Jan 1976
2429913600     16    # 1 Jan 1977
2461449600     17    # 1 Jan 1978
2492985600     18    # 1 Jan 1979
2524521600     19    # 1 Jan 1980
2571782400     20    # 1 Jul 1981
2603318400     21    # 1 Jul 1982
2634854400     22    # 1 Jul 1983
2698012800     23    # 1 Jul 1985
2776982400     24    # 1 Jan 1988
2840140800     25    # 1 Jan 1990
2871676800     26    # 1 Jan 1991
2918937600     27    # 1 Jul 1992
2950473600     28    # 1 Jul 1993
2982009600     29    # 1 Jul 1994
3029443200     30    # 1 Jan 1996
3076704000     31    # 1 Jul 1997
3124137600     32    # 1 Jan 1999
3345062400     33    # 1 Jan 2006
3439756800     34    # 1 Jan 2009
3550089600     35    # 1 Jul 2012
3644697600     36    # 1 Jul 2015
3965649301     37    # 31 Aug 2025

#h  09034b09 42918e8c e772586a a9ac7703 63880232

We can see that the leap file has been updated from the GNSS data with the correct leap seconds amount.

Summary

This article described the leap second maintenance challenge and the solution provided by the PTP operator, which automates updates and ensures precise time synchronization in OpenShift environments.