Leap second
A leap second is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC), to accommodate the difference between precise time (International Atomic Time (TAI), as measured by atomic clocks) and imprecise observed solar time (UT1), which varies due to irregularities and long-term slowdown in the Earth's rotation. The UTC time standard, widely used for international timekeeping and as the reference for civil time in most countries, uses TAI and consequently would run ahead of observed solar time unless it is reset to UT1 as needed. The leap second facility exists to provide this adjustment. The leap second was introduced in 1972. Since then, 27 leap seconds have been added to UTC, with the most recent occurring on December 31, 2016.[1] All have so far been positive leap seconds, adding a second to a UTC day; while it is possible for a negative leap second to be needed, one has not happened yet.
Because the Earth's rotational speed varies in response to climatic and geological events,[2] UTC leap seconds are irregularly spaced and unpredictable. Insertion of each UTC leap second is usually decided about six months in advance by the International Earth Rotation and Reference Systems Service (IERS), to ensure that the difference between the UTC and UT1 readings will never exceed 0.9 seconds.[3][4]
This practice has proven disruptive, particularly in the twenty-first century and especially in services that depend on precise timestamping or time-critical process control. And since not all computers are adjusted by leap-second, they will display times differing from those that have been adjusted.[5] After many years of discussions by different standards bodies, in November 2022, at the 27th General Conference on Weights and Measures, it was decided to abandon the leap second by or before 2035.[6][7]
Issues created by insertion (or removal) of leap seconds[edit]
Calculation of time differences and sequence of events[edit]
To compute the elapsed time in seconds between two given UTC dates requires the consultation of a table of leap seconds, which needs to be updated whenever a new leap second is announced. Since leap seconds are known only 6 months in advance, time intervals for UTC dates further in the future cannot be computed.
Implementation differences[edit]
Not all clocks implement leap seconds in the same manner. Leap seconds in Unix time are commonly implemented by repeating 23:59:59 or adding the time-stamp 23:59:60. Network Time Protocol (SNTP) freezes time during the leap second,[60] some time servers declare "alarm condition". Other schemes smear time in the vicinity of a leap second, spreading out the second of change over a longer period. This aims to avoid any negative effects of a substantial (by modern standards) step in time.[61][62] This approach has led to differences between systems, as leap smear is not standardized and several different schemes are used in practice.[63]
Textual representation of the leap second[edit]
The textual representation of a leap second is defined by BIPM as "23:59:60". There are programs that are not familiar with this format and may report an error when dealing with such input.
Binary representation of the leap second[edit]
Most computer operating systems and most time distribution systems represent time with a binary counter indicating the number of seconds elapsed since an arbitrary epoch; for instance, since 1970-01-01 00:00:00 in POSIX machines or since 1900-01-01 00:00:00 in NTP. This counter does not count positive leap seconds, and has no indicator that a leap second has been inserted, therefore two seconds in sequence will have the same counter value. Some computer operating systems, in particular Linux, assign to the leap second the counter value of the preceding, 23:59:59 second (59–59–0 sequence), while other computers (and the IRIG-B time distribution) assign to the leap second the counter value of the next, 00:00:00 second (59–0–0 sequence). Since there is no standard governing this sequence, the timestamp of values sampled at exactly the same time can vary by one second. This may explain flaws in time-critical systems that rely on timestamped values.[64]
Other reported software problems associated with the leap second[edit]
Several models of global navigation satellite receivers have software flaws associated with leap seconds:
Several software vendors have distributed software that has not properly functioned with the concept of leap seconds:
Some businesses and service providers have been impacted by leap-second related software bugs:
There were misplaced concerns that farming equipment using GPS navigation during harvests occurring on 31 December 2016, would be affected by the 2016 leap second.[86] GPS navigation makes use of GPS time, which is not impacted by the leap second.[87]
Due to a software error, the UTC time broadcast by the NavStar GPS system was incorrect by about 13 microseconds on 25–26 January 2016.[88][89]
Workarounds for leap second problems[edit]
The most obvious workaround is to use the TAI scale for all operational purposes and convert to UTC for human-readable text. UTC can always be derived from TAI with a suitable table of leap seconds. The Society of Motion Picture and Television Engineers (SMPTE) video/audio industry standards body selected TAI for deriving timestamps of media.[90]
IEC/IEEE 60802 (Time sensitive networks) specifies TAI for all operations. Grid automation is planning to switch to TAI for global distribution of events in electrical grids. Bluetooth mesh networking also uses TAI.[91]
Instead of inserting a leap second at the end of the day, Google servers implement a "leap smear", extending seconds slightly over a 24-hour period centered on the leap second.[62] Amazon followed a similar, but slightly different, pattern for the introduction of the 30 June 2015, leap second,[92] leading to another case of the proliferation of timescales. They later released an NTP service for EC2 instances which performs leap smearing.[93] UTC-SLS was proposed as a version of UTC with linear leap smearing, but it never became standard.[94]
It has been proposed that media clients using the Real-time Transport Protocol inhibit generation or use of NTP timestamps during the leap second and the second preceding it.[95]
NIST has established a special NTP time server to deliver UT1 instead of UTC.[96] Such a server would be particularly useful in the event the ITU resolution passes and leap seconds are no longer inserted.[97] Those astronomical observatories and other users that require UT1 could run off UT1 – although in many cases these users already download UT1-UTC from the IERS, and apply corrections in software.[98]