A leap second is a one-second adjustment applied to Coordinated Universal Time (UTC) to compensate for the Earths rotational speed fluctuations, to ensure that UTC closely reflects mean solar time.
The adjustment is decided by the International Earth Rotation & Reference Systems Service (IERS) and is confirmed six months ahead of the expected application. Leap seconds can be introduced at the end of the last day of June or December UTC, depending on the evolution of UT1-TAI.
The adjustment can be either to add an extra second or remove a second from the UTC time. This document describes how the Tekron clocks will behave when a leap second correction is applied.
TIME DISPLAYED ON LCD
On the 30th of June or 31st of December UTC, if a leap second is to be added, the sequence of the time displayed on the clock will count up to 60 seconds. For example:
23h 59m 58s
23h 59m 59s
23h 59m 60s
00h 00m 00s (0 seconds on new UTC day)
On the 30th of June or 31st of December UTC, if a leap second is to be removed, the sequence of the time displayed on the clock display will be:
23h 59m 57s
23h 59m 58s
00h 00m 00s
IRIG-B
IRIG-B Time
On the 30th of June or 31st of December UTC, if a leap second is to be added, the sequence of the time conveyed in the IRIG-B data will count up to 60 seconds. For example:
23h 59m 58s
23h 59m 59s
23h 59m 60s
00h 00m 00s (0 seconds on new UTC day)
On the 30th of June or 31st of December UTC, if a leap second is to be removed, the sequence of the time displayed on the clock display will be:
23h 59m 57s
23h 59m 58s
00h 00m 00s
IRIG-B C37.118 Extension
If the C37.118.1 IRIG-B extensions are enabled, then the bits 60 and 61 will be set for the minute prior to the adjustment being applied. The meanings of these two bits are:
|
Bit |
Description |
Value |
|
60 |
Leap second pending |
Set if a leap second adjustment is pending for the 1 minute prior to the change and cleared at the start of the UTC day. |
|
61 |
Subtract leap second |
If not set, then the leap second adjustment will result in 1 second being added to the time. If set then the leap second adjustment will result in 1 second being subtracted from the time. |
IRIG-B Binary Seconds
On the 30th of June or 31st of December UTC, if a leap second is to be added, the sequence of the time conveyed in IRIG-B, binary second data will repeat the first second of the next UTC day as the leap second is applied
86398
86399
86400
86400 (0 seconds on new UTC day)
On the 30th of June or 31st of December UTC, if a leap second is to be removed, the sequence of the time conveyed in IRIG-B binary second data will skip the last second in the UTC day:
86397
86398
86400 (0 seconds on new UTC day)
DCF-77
The DCF-77 Simulated signal is a time code based on a 1 pulse per second signal where the pulse width varies according to the data encoded. The signal is effectively a 1 bit per second data signal where:
100 mS pulse width = "0"
200 mS pulse width = "1"
There is no pulse sent 1 second before the “on time” pulse which is used to identify the start of each minute. The date/time information is therefore sent over the period between minute pulses along with some control/flag values.
Bit 19 (on 19th second each minute) gives the Leap Second announcement and is sent during the hour before the leap second is to be applied.
On the 30th of June or 31st of December UTC, if a leap second is to be added, there is no pulse sent on the 60th second instead of the 59th second. If a leap second is to be removed, then no pulse is sent on the 58th second and the next second denotes the start of the next minute.
NTP
NTP
NTP counts the time in seconds using a 64-bit unsigned seconds value since the start of an “era” or epoch.
These 64 bits comprise of two 32 bit values where the first 32 bits hold the number of integer seconds since the start of the NTP era, and the second 32 bits represents the fraction of a second of the timestamp.
The 32-bit fraction portion of the timestamp translates to a precision of 1/232 S eg approximately 233pS, however, the real accuracy of the NTP timestamp is likely to be around 15µS. This is due to the variable packet delays traversing the network especially those caused by network switches and routers. Typical results range from a few microseconds in PPS-assisted primary servers to tens of milliseconds in widely dispersed Internet networks.
Because the seconds are held by a 32 unsigned value the seconds counter overflows after 232 = 4294967296 seconds or approximately 136 years.
As NTP conveys the time in seconds in reference to the preceding era (00h 00m 00s 1st January 1900 was the first era) then the next NTP era will begin at 06:28:16 on the 7th February 2036.
NTP clients manage the application of the leap second as the NTP packets include a leap second flag, which informs the user that a leap second is imminent and applies the leap second at the next valid transition. The Leap Indicator flag is present up to 24 hours prior to the application of the leap second and is set as below:
‘00’ No Leap second (flag not set).
‘01’ add a second
‘10’ subtract a second
‘11’ means the server is currently unsynchronized.
When adding a leap second, the NTP server simply repeats the last second of the UTC day (23:59:59) with the fractional part of the second set to .999999999. When deleting a second, the last second (23:59:59) is skipped.
There are four versions of NTP (v1, v2, v3 and v4) where the NTP packet content is the same. Each variant improved the performance and accuracy of NTP and introduced a management protocol and cryptographic authentication scheme which have both survived into NTPv4.
SNTP
A less complex implementation of NTP, using the same protocol but without requiring the storage of state over extended periods of time is known as the Simple Network Time Protocol (SNTP). It is used in applications where high accuracy timing is not required.
By disregarding drift values and using simplified ways of system clock adjustment methods (often simple time-stepping), SNTP achieves only a low-quality time synchronization when compared with a full NTP implementation.
While a full-featured NTP server or client reaches a very high level of accuracy and avoids abrupt timesteps as much as possible by using different mathematical and statistical methods and smooth clock speed adjustments, SNTP can only be recommended for simple applications, where the requirements for accuracy and reliability are not too demanding.
PTP
Precision Time Protocol (PTP) increases the accuracy of the synchronisation of clocks compared to NTP to be in the order of 100nS by:
- Hardware Timestamps are included in the servers, clients and switches to capture timestamps of the frames at the physical layer.
- On-Wire Protocol operates primarily in a broadcast mode where a grandmaster provides synchronisation to multiple clients sharing the network. Alternatively, the protocol can operate in a master/slave message mode.
- Both NTP and PTP use crafted algorithms to improve accuracy and select among a possibly complex set of network paths. PTP uses the Best Master Clock BMC algorithm to select the optimal path to the grandmaster as a function of various quality measures, including hop count and choosing the best reference clock as master.
- Generally, the PTP system is implemented over a lightly loaded fast Ethernet segments. NTP is often implemented over networks that share demanding internet applications including speech and video.
By default, PTP uses the 00:00 January 1, 1970 epoch (although PTP v2 introduced the ability to use other epochs). All timestamps sent in the PTP packets are sent in a 64-bit format. The highest 32 bits represent an unsigned integer giving the number of seconds from the epoch start date/time. The lowest 32 bits are used to give the fractional part of the second as nanoseconds.
PTP is not subjected to leap seconds as the time base is International Atomic Time (TAI), however, the packets do contain information on current and pending leap seconds to enable downstream devices to calculate UTC or alternate time bases derived from UTC if required (i.e. Local Time or Local Daylight Time).
The PTP packets contain two leap second indicator flags:
PTP_LI_59 Set to 1 if a leap second is to be subtracted
PTP_LI_61 Set to 1 if a leap second is to be added.
These flags are set for the previous 12 hours before the UTC midnight.
The IEEE 1588 has extensions to the standard where extra information can be added to the PTP packets. In PTP Announce messages from the Grandmaster, the Alternate Time Offset indicator TLV may be used to pass extra values which include:
- Current offset: The alternate time is given by the sum of the current NTP time + this offset in seconds
The value of current Offset shall be the offset of the alternate time, in seconds, from the node’s time. The alternate time is the sum of this value and the node’s time. - Jump seconds: The value of jump Seconds shall be the size of the next discontinuity, in seconds, of the alternate time. A value of zero indicates that no discontinuity is expected. A positive value indicates that the discontinuity will cause the current Offset of the alternate time to increase.
- Time of next jump: The value of time Of Next Jump shall be the value of the second portion of the transmitting node’s time at the time that the next discontinuity will occur. The discontinuity occurs at the start of the second indicated by the value of time Of Next Jump.
The current UTC time can be derived from the current PTP time using the above TLV values.
As the time arrives that the UTC leap second is applied, the Current Offset and Jump Seconds field will be updated to reflect the new current values. Often at the time the leap second is applied, the detail of any future jump (leap second) is not known. The Time of next jump value will therefore often remain unchanged at the time the leap second is applied and will only change when any future change is published (may be months later).