Computer Time and Leap Seconds History and Timeline - UT1, TAI, UTC, Leap Smearing, and Who Decides When a Second Is Added

First Published: 2026-09-13
Last Updated: 2026-09-13

During a post-incident analysis, when comparing logs from two services, the timestamps differed by one second. Both clocks were synchronized with NTP, and the operators of both systems insisted their clocks were correct. The first question that typically arises in such situations is, "Which clock is wrong?" However, that question only provides half the answer. The other half is whether those two clocks are even reading the same time scale.

This article presents a timeline of who has been responsible for defining the length of a second and establishing UTC. It does not focus on how NTP is configured, nor does it collect accounts of incidents caused by leap seconds. Instead, it shows that the body that defined the second, the body that made the leap second system, and the body that announces the insertion of each leap second are separate. This is shown in the wording of the primary sources of each body. In 2022, one of these bodies decided to change the upper limit on the UT1-UTC difference, and in October 2026, a proposal to bring that change forward will be put to a vote.

Three Time Scales and Who Maintains Each

This timeline differs from other technical histories in one key aspect: the decision-making body and the announcement body are distinct, and their roles do not overlap. Resolutions of the CGPM (General Conference on Weights and Measures) hold the definition of the second and the formal definitions of TAI and UTC. The procedure for inserting leap seconds is outlined in ITU-R Recommendation TF.460-6. The IERS (International Earth Rotation and Reference Systems Service) decides and announces the insertion of each leap second, and Bulletin C is the document that carries the announcement. When asked who decides when a leap second is added, primary source documents provide two answers. CGPM and ITU-R define the system, while IERS decides on the insertion. This article keeps these two aspects separate.

This article does not address the merits of the system itself. It does not discuss whether leap seconds should have been abolished, nor does it evaluate the validity of leap smear (a method of smoothing leap seconds over time). It also avoids ranking providers against each other. Instead, it simply documents which documents specify what decisions were made on which dates, what the current status of those decisions is, and which time scale a computer is reading. It also refrains from speculating on the reasons behind decisions when official documentation does not provide them.

All information presented in this article was verified as of September 12, 2026. ⚠ This date has a special position for the subject of this article. The 28th CGPM will be held from October 13 to October 15, 2026, and a resolution concerning the handling of leap seconds will be put to a vote at that meeting. This article is written before that vote takes place.

Related articles on hidekazu-konishi.com:

Background and Method of Creating the Leap Second Timeline

Three Time Scales Behind the Word Time

The phrase "the time is correct" doesn't specify what exactly is being aligned. This article discusses three different time scales, each measuring something different.

UT1 — This time scale corresponds to the Earth's rotation angle. According to ITU-R Recommendation TF.460-6, UT1 is defined as UT0, obtained from direct astronomical observations, with a correction applied for polar motion. It is a scale directly corresponding to the angular position of the Earth's daily rotation. Because the Earth's rotation is not constant, one second of UT1 is not a fixed duration.
TAI — This is the International Atomic Time. It is a continuous scale, using the SI second as its unit, and BIPM (the International Bureau of Weights and Measures) calculates it from the data of atomic clocks in various countries. TF.460-6 notes that the origin of TAI is January 1, 1958, and also mentions that the CGPM adopted this in 1971. TAI does not include leap seconds.
UTC — This is Coordinated Universal Time. It progresses at the same rate as TAI, but is offset from TAI by an integer number of seconds. This offset is adjusted using leap seconds, which are added or removed to keep the difference between UTC and UT1 within 0.9 seconds. Most computer time and most civil time rest on UTC.

Annex 1 of TF.460-6 defines UTC as follows.

UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a
coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI
but differs from it by an integer number of seconds.

The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to
ensure approximate agreement with UT1.

⇒ Of these three scales, only UTC has leap seconds. UT1 is kept by the Earth, and TAI by atomic clocks. UTC fills the gap between the two with steps of an integer number of seconds. The current value of this offset is 37 seconds, and has not changed since January 1, 2017. This value is not a constant. It can change each time the IERS announces it in Bulletin C. This article places the issue number and date of those announcements in the timeline.

What a Computer Actually Reads

The distributed system the reader is designing does not directly read any of the three scales above. Instead, it reads the time provided by the operating system and protocols, and the specifications for each detail how they handle leap seconds. ⛔ Even when they all use the term "UTC," providers behave differently at the moment of a leap second. The table below summarizes findings from primary sources.

What is being read	Leap Second Handling	Primary Source
POSIX's seconds since the Epoch	Always counts a day as 86,400 seconds. The relationship to actual UTC is explicitly marked as "unspecified."	POSIX.1-2024 §4.19
Linux's CLOCK_REALTIME	Counts UTC seconds, but ignores leap seconds. NTP adjusts to UTC near leap seconds.	man-pages clock_gettime(2)
Linux's CLOCK_TAI	Counts leap seconds. The origin point is 10 seconds before CLOCK_REALTIME. Without the help of NTP, it behaves the same as CLOCK_REALTIME.	man-pages clock_gettime(2) (Linux 3.10 and later)
NTP (RFC 5905)	Based on UTC, and uses two bits of the Leap Indicator to warn of a leap second at the end of the month.	RFC 5905 §7.3
Leap-smeared time	Distributes one second across the time before and after the leap second. Within this window, it does not align with UTC.	RFC 8633 §3.7.1 and official documentation from various providers
PTP and GPS	RFC 7164 classifies IEEE 1588, GPS, and TAI as reference clocks that do not include leap seconds. However, AWS explicitly states that its PTP hardware clock inserts the leap second according to UTC.	RFC 7164 Table 2 and AWS EC2 User Guide
Windows System Time	Windows Server 2019 and Windows 10 October 2018 Update handle leap seconds at the platform level. Older operating systems have no notation such as `08:59:60` and instead correct the one second at the next synchronization.	Microsoft Learn

The relevant section in POSIX.1-2024 is as follows:

As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400
seconds.

The relationship between the actual date and time in Coordinated Universal Time, as determined by the
International Earth Rotation Service, and the system's current value for seconds since the Epoch is
unspecified.

⇒ Unix timestamps, even on a day with a leap second, only advance by 86,400 seconds. In the count, the final second of that day does not exist. This aspect will be addressed later in this article as the first of the ways a leap second breaks a computer. Since existing tools, such as the Unix Timestamp Converter Tool, already handle the conversion between Unix timestamps and calendar days, this article will not detail the conversion process.

The Linux man-pages state the following regarding CLOCK_REALTIME:

This clock normally counts the number of seconds since 1970-01-01 00:00:00 Coordinated Universal Time
(UTC) except that it ignores leap seconds; near a leap second it is typically adjusted by NTP to stay
roughly in sync with UTC.

⚠ On the same Linux system, there can be a clock that ignores leap seconds and another that accounts for them, existing simultaneously. While CLOCK_TAI has been available since Linux 3.10, in environments where it doesn't receive leap second information from NTP, it returns the same value as CLOCK_REALTIME. Which one is being read cannot be known without reading the code.

Who Decides What - Four Bodies and One Distinction

The core of this article lies here. Four bodies are involved in leap seconds, and what each decides is different.

Body	Decides	Does Not Decide	Document of Decision
CGPM (General Conference on Weights and Measures), and its subordinate bodies CIPM and CCTF	The definition of the SI second. The formal definitions of TAI and UTC. The decision to change the upper limit of the difference between UT1 and UTC.	Whether to insert each individual leap second.	CGPM Resolutions. CIPM Decisions.
BIPM (International Bureau of Weights and Measures)	The calculation of TAI and UTC. The publication of the difference between each country's UTC(k).	Whether to insert each individual leap second. The value of the upper limit.	Circular T
ITU-R (Radiocommunication Sector of the International Telecommunication Union)	The procedure for inserting a leap second. The months in which one can be inserted, the announcement deadline, and the notation 23h 59m 60s. The position of UTC within the Radio Regulations.	The upper limit value itself (since 2023 it has taken the form of endorsing the decisions made by CGPM).	Recommendation ITU-R TF.460-6. WRC Resolution 655
IERS (International Earth Rotation and Reference Systems Service)	Whether to insert each individual leap second, and its date. The observation and prediction of the difference between UT1 and UTC.	The system itself. The upper limit value.	Bulletin C

Annex 1 of TF.460-6 defines the procedures for leap seconds in three sections.

2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference
should be given to the end of December and June, and second preference to the end of March and September.

2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following
month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s
of the first day of the following month (see Annex 3).

2.3 The IERS should decide upon and announce the introduction of a leap-second, such an announcement to be
made at least eight weeks in advance.

⇒ The ITU-R wrote the procedure, and within that procedure it delegates the decision and the announcement to the IERS. The BIPM's time metrology page also states that UTC is obtained from TAI by inserting leap seconds on the advice of the IERS.

UTC is obtained from International Atomic Time (TAI) by the insertion of leap seconds according to the
advice of the International Earth Rotation and Reference Systems Service (IERS) to ensure approximate
agreement with the time derived from the rotation of the Earth.

⛔ Therefore, when answering the question "Who decides leap seconds?", the answer has to be split in two. The CGPM and the ITU-R decided the leap second system, its upper limit, and the procedure for insertion. The IERS decides that an individual leap second will be inserted and announces it. The IERS is the announcing body, not the body that makes the system. Furthermore, it was CGPM, not IERS, that decided to change the upper limit on the UT1-UTC difference in 2022. The timeline in this article writes the body for each row according to this distinction.

The Primary Sources This Article Used

Each row includes the URL for the corresponding primary source material. The following families of sources were used.

BIPM CGPM Resolutions and CIPM Decisions — English translations of resolutions from the 13th (1967), 14th (1971), 15th (1975), 26th (2018), and 27th (2022) meetings. The PDF documents of the convocation of the 28th meeting (2026) and of the draft resolutions. The report that the CCTF attached to draft resolution C. The "decides" and "requests" sections of each resolution were read verbatim.
IERS Bulletin C and Data Files — The full text of the issues this article checked, including Bulletin C 72. Also, the Leap_Second.dat and UTC-TAI.history files. The dates of leap second insertions and the difference between TAI and UTC were cross-referenced using these two files, along with the tai-utc.dat file from the U.S. Naval Observatory and the NIST webpage.
ITU-R Recommendations, Resolutions, and Press Releases — PDF document for Recommendation ITU-R TF.460-6. PDF document for Resolution 655 (Rev.WRC-23). ITU press releases from 2012 and 2015.
IETF RFCs — RFC 958, RFC 5905, RFC 7164, RFC 8633. These are cited by number and section.
The Open Group's POSIX.1-2024 and Linux man-pages — Documents defining the time representation used by computers.
Official Documentation from Cloud Providers and OS Vendors — For AWS, the EC2 User Guide, What's New, and official blog. For Google, the leap smear page on developers.google.com and Compute Engine documentation. For Microsoft, Microsoft Learn and the official blog on Tech Community.
Primary Records of Incidents Published by Developers — Two Linux kernel commits. Cloudflare's post-incident analysis blog.

⛔ Secondary media and summary articles were not treated as primary sources. This topic has a great many secondary articles, and many assert that leap seconds have been abolished. The abolition, the change to the limit, and the proposal are three different things, and this article distinguishes them document by document.

⚠ The sources this article checks against include a family that the existing publications on this site have not used. The primary source materials for units of measurement and time were treated as specifications equivalent to those of IETF RFCs and NIST documents. There are two reasons for this. First, the definition of UTC and the procedures for leap seconds are only documented in resolutions from CGPM and recommendations from ITU-R, and RFC 5905 itself delegates the definition of UTC to TF.460. Second, the AWS EC2 User Guide specifically references the decisions of the 27th CGPM, so it was necessary to verify the accuracy of the cloud provider's descriptions by referring back to that resolution. The information regarding AWS was obtained from the aws-knowledge MCP, while the rest was obtained directly from the official site of each body.

The Type Column

Each row in the timeline includes a type designation. This is to avoid describing the date a resolution was adopted, the date it took effect, and the date a leap second was actually inserted with the same word. The following seven values are used:

Adopted — Rows indicating the date a resolution, recommendation, or decision was adopted. This is the date of adoption, not the date of effect.
Effective — Rows indicating the date a decision took effect. For example, May 20, 2019, when the SI revisions came into effect.
Inserted — Rows indicating the date a leap second was actually inserted. The insertion date is given in UTC.
Announced — Rows indicating the date an announcement was made. This includes IERS Bulletin C and ITU press releases announcing postponed decisions.
Published — Rows indicating the date a document was published. This includes RFCs, blog posts, kernel commits, the convocation, and reports.
Launched — Rows indicating the date a service or feature was launched.
Scheduled — Rows representing dates that were still in the future as of the verification date. There is one row of this type in this article.

Why the Date Precision Differs from Row to Row

This article does not provide daily precision for every row. The reason lies in the nature of the primary source materials.

CGPM resolutions only include the dates of the sessions. The 27th CGPM took place from 2022-11-15 to 2022-11-18, but the BIPM website does not specify the date that Resolution 4 was adopted. This article uses monthly precision when the session duration falls within one month, and annual precision when it spans two months.
CIPM decisions only include the session number and year. For Decision CIPM/115-5 (2026), the month is aligned with the March 2026 meeting referenced in another decision from the same session.
RFCs only include the month and year of publication.
ITU-R recommendations only include the month and year of approval. Recommendation TF.460-6 is dated 02/2002.
Bulletin C includes dates within the text. ⚠ The dates displayed in the IERS archive listings are file update dates, not publication dates. This article uses the dates found within the main text of each issue.
Kernel commits have two dates: the author date and the committer date. This article uses the author date.

⚠ This article does not invent dates to make the precision uniform. While some secondary sources include daily dates for resolutions, the primary source materials only indicate the session dates.

What This Timeline Does Not Include

What was not included, and why, is stated up front.

The Year 2000 problem and the Year 2038 problem. Both relate to integer overflows and expression formats, and are separate topics from leap seconds. This article does not address the Year 2038 problem. The existing tool covers the range of Unix timestamps.
Configuration steps for time synchronization in EC2, VMware, or Linux. Existing publications hold the IP addresses of Amazon Time Sync Service and the chrony configuration. This article only describes which time scale that configuration reads.
Internal specifications of IEEE 1588. How the PTP time scale is defined is not included, because this article did not consult the standard itself. This article only addresses how RFC 7164 classifies IEEE 1588 and how AWS describes its own PTP hardware clock.
Details regarding GPS time. Primary sources for the difference between GPS and UTC could not be reached as of the verification date. This article only touches on it through the classification in RFC 7164.
Evaluations of the parties involved in specific incidents. Primary records of incidents are cited to illustrate the types of failures that occurred. Any assessment of the responses of those involved is not included.
Academic papers dealing with leap seconds. The CCTF report cites papers estimating the probability of a negative leap second, but this article treats them only as the report's description.

What This Article Leaves to Other Articles

This article covers only the lineage of the bodies that decide time. The configuration and design aspects are already covered in existing publications.

The configuration of time synchronization for EC2 instances, and the NTP item within DHCP option sets are detailed in the existing publication Running VMware Workloads on AWS with Amazon EVS. This article does not provide configuration instructions.
The design rationale for Amazon Time Sync Service as a link-local address is covered in the existing publication IPv6-First VPC Design on AWS. This article does not discuss the design principles of addressing.
The discussion of combining precision time placement groups and PTP hardware clocks with cluster placement groups is found in the existing publication Elastic Fabric Adapter and the AWS Network Fabric. This article will only address how those clocks handle leap seconds.
The design of transaction ordering based on the assumption of accurate time is covered in the existing publication Amazon Aurora DSQL Design Decision Guide. This article will focus on who guarantees that assumption.
The conversion between Unix timestamps and calendar days is covered in the existing tool Unix Timestamp Converter Tool.
As an example of embedding UTC milliseconds in documentation, the attestation document in the existing publication AWS Nitro Enclaves and Confidential Computing on AWS serves as a case study. This article will not discuss the meaning of those fields.
Two articles being released concurrently with this one explore the same principle: numbers are not inherent but emerge when someone defines a unit of measurement. The first, regarding LLM benchmarks, is covered in LLM Benchmark History and Timeline, and the second, regarding AWS service quotas, is covered in AWS Service Quotas History and Timeline. This article will not discuss either benchmarks or quotas.

Leap Second Governance Timeline (Updates from January 1, 1958)

The following governance timeline lists the bodies that have decided the second, UTC, and leap seconds. The rows are in ascending order of date, and each row includes a link to its primary source. The "Who" column gives the body that issued the document of that row. For rows of leap second insertions, it gives the body that announced the insertion.

Use the following index to navigate by year:

1958 - Seconds are separated from astronomical time, and UTC takes on its current form.
1975 - UTC is endorsed as the basis of civil time, the IERS begins operations, and TF.460-6 fixes the procedure.
2005 - Computers encounter leap seconds.
2017 - Cloud time services smear, and the definitions of TAI and UTC become resolutions.
2022 - The CGPM decides, and the ITU endorses.
2025 - A draft resolution brings the date forward, and the vote is still ahead.

1958-1972 - The Second Leaves the Sky, and UTC Takes Its Present Form

During this period, all the foundational elements of the subject matter of this article came together. ⚠ The definition of the second left the Earth in 1967, and the leap second system began in 1972. The sequence of these five years clarifies the purpose for which the leap second was created.

Date	Who	Type	Summary
1958-01-01	`TAI`	`Effective`	The origin of TAI. Annex 1 of TF.460-6 defines TAI as a continuous scale formed from the data of each institution's clocks, based on the SI second, and notes its origin as `from the origin 1 January 1958 (adopted by the CGPM 1971)`. ⚠ This row indicates the origin date, not the date of adoption. The adoption occurred in 1971. The guide to the IERS Bulletin C also states that the origin was placed so that the difference between UT1 and TAI is approximately 0 on 1958-01-01. References: Recommendation ITU-R TF.460-6
1961-01-01	`UTC`	`Effective`	The beginning of UTC, prior to its current form. IERS's UTC-TAI.history records the difference between TAI and UTC from 1961-01-01 onwards, using a formula that adds a term proportional to the number of days to a constant. During this period, UTC followed the Earth's rotation through a rate offset and small steps, rather than through an integer-second offset from atomic time. ⇒ The leap second system was created to replace this method. The transition occurred in the row for 1972-01-01. References: UTC-TAI.history / tai-utc.dat
1967-10	`CGPM`	`Adopted`	Resolution 1 of the 13th CGPM defined the second based on the transition of cesium atoms. The meeting took place from 1967-10-10 to 1967-10-16. The definition reads: `The second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom` ⇒ From this date, the length of a second became independent of both the Earth's rotation and its orbit. The need for leap seconds is a consequence of this definition. Since the second is now independent of Earth, any adjustment requires introducing step changes in integer seconds. ⚠ The spelling remains as in the original text. References: Resolution 1 of the 13th CGPM (1967)
1970	`ITU-R`	`Adopted`	The CCIR (the predecessor of ITU-R) completed the definition of UTC, including leap seconds. Resolution 655 (Rev.WRC-23) states this in recognizing c). `that the original definition of the international reference time scale UTC resulted from work completed in 1970 by the International Radio Consultative Committee (CCIR) of ITU, in full cooperation with CGPM;` TF.460-6 itself lists the revision history as `(1970-1974-1978-1982-1986-1997-2002)`. ⚠ This row only includes the year. The original text of the 1970 recommendation has not been verified in this article. References: Resolution 655 (Rev.WRC-23) / Recommendation ITU-R TF.460-6
1971-10	`CGPM`	`Adopted`	Resolution 1 of the 14th CGPM requested that CIPM define International Atomic Time (TAI). The meeting took place from 1971-10-04 to 1971-10-07. The resolution, considering that the second had been defined by the frequency of cesium atoms since 1967 and that an international atomic time scale was therefore necessary, requested the CIPM `to give a definition of International Atomic Time`. ⚠ This resolution did not define TAI itself, but rather requested that a definition be created. The formal definition would wait until the row for 2018. References: Resolution 1 of the 14th CGPM (1971)
1972-01-01	`UTC`	`Effective`	The beginning of UTC in its current form. From this date, the difference between TAI and UTC became an integer number of seconds, with an initial value of 10 seconds. IERS's Leap_Second.dat, UTC-TAI.history, and the U.S. Naval Observatory's tai-utc.dat all record that an integer difference of 10 seconds began on this date, and that the term proportional to the number of days became 0. RFC 5905 also marks this date as a transition point. `UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost.` ⇒ The UTC that computer time assumes is the UTC from this date onward. References: Leap_Second.dat / RFC 5905
1972-06-30	`BIH`	`Inserted`	The first leap second was inserted. The difference between TAI and UTC changed from 10 seconds to 11 seconds. The NIST page states: `The first leap second was inserted into the UTC time scale on June 30, 1972.` ⚠ The "Who" field is listed as BIH because BIH was responsible for Earth rotation services prior to 1988. IERS's history page states that IERS took over the Earth rotation services from BIH in 1988. The original announcement documents from that time have not been verified in this article. References: Leap_Second.dat / NIST Leap Seconds

1975-2002 - UTC Becomes Civil Time, the IERS Takes Over, and TF.460-6 Fixes the Procedure

During this period, the roles of the two bodies responsible for establishing standards and the body responsible for announcements took on their current form. The CGPM endorsed UTC as the basis of civil time, the IERS began its operations, and an ITU-R recommendation reached its current version.

Date	Who	Type	Summary
1975	`CGPM`	`Adopted`	Resolution 5 of the 15th CGPM strongly endorsed UTC as the basis of civil time. Held from May 27 to June 3, 1975, the resolution recognized that UTC was widely used and broadcast in time signals, stating that `this Coordinated Universal Time provides the basis of civil time, the use of which is legal in most countries` and that `this usage can be strongly endorsed` ⇒ UTC, with its leap seconds, was thereby endorsed from the metrology side as the basis of civil time in each country. References: Resolution 5 of the 15th CGPM (1975)
1979	`ITU-R`	`Adopted`	WARC-79 included UTC in the Radio Regulations. Resolution 655 (Rev.WRC-23) recognizes that WARC-79 incorporated UTC into the Radio Regulations, and that subsequently, UTC has been used as a primary time scale for telecommunications networks. ⚠ This row only provides the year, and the original WARC-79 document has not been verified. This article places this row as the point at which the ITU-R came to hold UTC in a regulatory document. References: Resolution 655 (Rev.WRC-23)
1985-09	`IETF`	`Published`	RFC 958 proposed the Network Time Protocol (NTP) and carried the leap second warning bits. The two-bit Leap Indicator is used to signal that the next minute will be either 61 or 59 seconds. The RFC also states, `A standard mechanism to effect leap-second correction is not a part of this specification.` ⇒ This established a division of responsibility: while NTP could provide a warning, the actual implementation of leap second corrections was left to individual implementations. This division of responsibility remains unchanged as of RFC 5905 in 2010. References: RFC 958
1988-01-01	`IERS`	`Effective`	The International Earth Rotation Service (IERS) began operations. The IERS history page states: `The International Earth Rotation Service (IERS) was established in 1987 by the International Astronomical Union and the International Union of Geodesy and Geophysics and it began operation on 1 January 1988.` The same page notes that the IERS took over the earth-rotation section of the Bureau International de l'Heure (BIH), and that `the activities of BIH on time are continued at Bureau International des Poids et Mesures (BIPM)` ⇒ This marked a division of one organization's work into two: Earth rotation observation went to the IERS, and the calculation of time scales went to the BIPM. Every Bulletin C whose text this article checked is dated after this day. The organization was renamed to its current name in 2003. References: History of the IERS
2002-02	`ITU-R`	`Adopted`	Recommendation ITU-R TF.460-6 was approved. The ITU recommendation page indicates that it was approved in February 2002 and that this version is incorporated by reference in the Radio Regulations. ⛔ As of the verification date, it remains in force and is the current document that defines the procedure for leap seconds. Annex 1 defines UT1, TAI, and UTC, specifies the tolerance that UTC and UT1 should not differ by more than 0.9 seconds, establishes the months in which leap seconds are inserted and the announcement deadline, and defines the notation 23h 59m 60s. ⇒ The three items quoted in the section on who decides what are from this version. References: Recommendation ITU-R TF.460

2005-2016 - Computers Meet the Leap Second

From 1999 to 2005, no leap second was inserted for seven years. Following this gap, five leap seconds were inserted, and each time, providers and operating systems documented their handling of the event. The rows for this period mix leap second insertions with primary records from providers and operating systems.

Date	Who	Type	Summary
2005-12-31	`IERS`	`Inserted`	The first leap second in seven years was inserted. The announcement was made in Bulletin C 30 (Paris, 4 July 2005), and the difference between TAI and UTC shifted from 32 seconds to 33 seconds. ⚠ The previous leap second was inserted on December 31, 1998. From 1999 to 2005, no leap seconds were added, and computers that began operating during this period had not experienced a leap second. This article does not list individual failures that followed, but the 2012 rows come after this gap. References: Bulletin C 30
2008-12-31	`IERS`	`Inserted`	A leap second was inserted, as announced in Bulletin C 36 (Paris, 4 July 2008). The difference between TAI and UTC became 34 seconds. ⇒ Google began using leap smear with this leap second. Google's leap smear page states, `Since 2008, instead of applying leap seconds to our servers using clock steps, we have "smeared" the extra second across the hours before and after each leap.` The same page describes the 2008 method as a 20-hour cosine smear before the leap second, and states that this method was used only that once. References: Bulletin C 36 / Leap Smear
2010-06	`IETF`	`Published`	RFC 5905 defined NTP version 4. The Leap Indicator value is 0 for no warning, 1 for the last minute of the day being 61 seconds, 2 for 59 seconds, and 3 for unsynchronized. ⚠ It does not define the leap second itself. RFC 5905 states that ITU-R TF.460 defines the UTC time scale, delegating the handling of leap seconds to that recommendation. ⇒ NTP carries leap seconds but does not define them. References: RFC 5905
2011-09-15	`Google`	`Published`	Google published an official blog post explaining leap smear. The post was titled "Time, technology and leaping seconds." ⚠ Only the title and date were confirmed. The content of the post could not be retrieved on the verification date with the means used for this article, so the description of the method relies on the 2008 row and the leap smear page cited in a later section. References: Time, technology and leaping seconds
2012-01-19	`ITU-R`	`Announced`	The ITU-R Radiocommunication Assembly RA-12 deferred the decision on abolishing the leap second. An ITU press release stated, `The ITU Radiocommunication Assembly has reached an important decision to defer the development of a continuous time standard in order to address the concerns of countries that use the current system of the leap second in Coordinated Universal Time (UTC).` The decision was sent to the 2015 assembly and the WRC. ⚠ At this point, ITU-R, not CGPM, was considering the future of leap seconds. It was the CGPM that decided ten years later. References: ITU Radiocommunication Assembly defers decision to eliminate the leap second
2012-03-15	`Linux`	`Published`	A fix entered the Linux kernel for a livelock in the leap second insertion path. The commit description begins, `Since commit 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 the ntp subsystem has used an hrtimer for triggering the leapsecond adjustment. However, this can cause a potential livelock.` ⚠ The date is the author date; the commit date was March 23, 2012. This fix entered a little more than three months before the next leap second. References: ntp: Fix leap-second hrtimer livelock
2012-06-30	`IERS`	`Inserted`	A leap second was inserted, as announced in Bulletin C 43 (Paris, 5 January 2012). The difference between TAI and UTC became 35 seconds. ⇒ This leap second, as the fix in the next row shows, exposed another problem in the Linux timer mechanism. References: Bulletin C 43
2012-07-10	`Linux`	`Published`	A fix entered for an issue where kernel timers fired one second early or late after a leap second. The commit description states, `The timekeeping code misses an update of the hrtimer subsystem after a leap second happened. Due to that timers based on CLOCK_REALTIME are either expiring a second early or late depending on whether a leap second has been inserted or deleted until an operation is initiated which causes that update.` ⚠ At the leap second that followed the March fix, another path remained. This article treats this as the third type of breakage in a later section. References: timekeeping: Fix leapsecond triggered load spike issue
2014-03	`IETF`	`Published`	RFC 7164 defined the relationship between RTP and leap seconds, classifying reference clocks by whether they carry leap seconds. Table 2 classifies `IEEE 1588, GPS, TAI` as `Non-leap-second-bearing` and NTP as `Leap-second-bearing`. ⇒ Even within IETF documentation, PTP and GPS are placed on the side that does not account for leap seconds. This article uses this classification as a basis for the table of times that computers read. References: RFC 7164
2015-05-18	`AWS`	`Published`	AWS published an official blog post announcing its handling of the upcoming leap second in the following month. The post focused on managed services, stating that one second would be spread over the 24 hours from noon on June 30 to noon on July 1. It also stated, `During these 24 hours, AWS clocks may be up to 0.5 second behind or ahead of the standard civil time` ⛔ EC2 instances are excluded. `Each EC2 instance has its own clock and is fully under your control; AWS does not manage instance clocks.` ⇒ At this point, whether a provider smears and whether the reader's instance reads smeared time were still separate matters. The two are connected in the 2017 row. References: Look Before You Leap - The Coming Leap Second and AWS
2015-06-30	`IERS`	`Inserted`	A leap second was inserted, as announced in Bulletin C 49 (Paris, 5 January 2015). The difference between TAI and UTC became 36 seconds. ⇒ The handling that the AWS blog post in the previous row announced was for this leap second. References: Bulletin C 49
2015-11-19	`ITU-R`	`Announced`	WRC-15 again put off abolishing the leap second and decided to keep applying UTC as described in TF.460-6. An ITU press release stated that further research on future time scales was necessary, and that UTC would continue to be applied as defined in TF.460-6 by BIPM. It also set the next deadline, stating, `A report will be considered by the World Radiocommunication Conference in 2023.` ⚠ The WRC is a conference of ITU member states. This article writes the WRC's decision as an ITU-R row. References: Coordinated Universal Time (UTC) to retain "leap second"
2016-12-31	`IERS`	`Inserted`	A leap second was inserted, as announced in Bulletin C 52 (Paris, 6 July 2016). The difference between TAI and UTC became 37 seconds, and as of the verification date this is the last leap second. The U.S. Naval Observatory's page also states that the last leap second was inserted at the end of December 2016. ⇒ This value of 37 seconds has not changed through Bulletin C 72 on the verification date. References: Bulletin C 52 / Leap Second Announcement (USNO)

2017-2020 - Cloud Time Services Smear, and the Definitions Are Written Down

During this period, smearing moved from provider operations to a published policy, and the formal definitions of TAI and UTC took the form of a resolution. Separate bodies drove these two developments, and they did not yet reference each other.

Date	Who	Type	Summary
2017-01-01	`Cloudflare`	`Published`	Cloudflare published the cause of the effect that the previous day's leap second had on its DNS service. The post-incident analysis states, `The root cause of the bug that affected our DNS service was the belief that time cannot go backwards.` ⚠ This article cites this record as the primary record for the type in which time goes backward. It does not judge the response. References: How and why the leap second affected Cloudflare DNS
2017-11-29	`AWS`	`Launched`	Amazon launched the Amazon Time Sync Service. The What's New post states, `The Amazon Time Sync Service automatically smooths out (smears) leap seconds that are periodically added to UTC, so that customers do not have to worry about application errors due to their addition. In the future, we will also provide mechanisms for accessing non-leap smeared time.` ⇒ The smear that in 2015 applied only on the managed-service side now reached the time that EC2 instances read. At the same time, access to time that is not smeared was announced for the future. References: Introducing the Amazon Time Sync Service
2018-07-18	`Microsoft`	`Published`	Microsoft published an explanation of leap second support in Windows Server 2019 on their official blog. The article describes how Windows Server 2019 handles leap seconds in line with UTC, supporting both positive and negative leap seconds, and explicitly states, `As noted above, we will not include a leap second smearing option.` ⚠ The date refers to the date listed on the article, `First published on TECHNET on Jul 18, 2018`. The current location displays the post-migration date. References: Top 10 Networking Features in Windows Server 2019: #10 Accurate Network Time
2018-11	`CGPM`	`Adopted`	Resolution 2 of the 26th CGPM formally defined TAI and UTC. The meeting took place from 2018-11-13 to 2018-11-16. The resolution considered that, since 1971, there had been no official definition of TAI, and confirmed that TAI is a continuous scale produced by BIPM, and that UTC differs from TAI by only an integer number of seconds, stating, `UTC produced by the BIPM, based on TAI, is the only recommended time scale for international reference and the basis of civil time in most countries` ⇒ The definition requested in 1971 took the form of a resolution 47 years later. Resolution 1 of the same meeting revised the entire SI system. References: Resolution 2 of the 26th CGPM (2018)
2019-05-20	`CGPM`	`Effective`	The revised SI system came into effect. Resolution 1 of the 26th CGPM explicitly stated `effective from 20 May 2019` and defines the second by fixing the cesium 133 hyperfine transition frequency at 9 192 631 770 Hz. ⚠ While the resolution was adopted in November 2018, it came into effect in May 2019. The "Type" column is included to differentiate between the adoption and effective dates, rather than using the same term for both. References: Resolution 1 of the 26th CGPM (2018)
2019-07	`IETF`	`Published`	RFC 8633 became BCP 223, the best current practice for NTP operations, and defined how leap smear is to be handled. Section 3.7.1 states that the purpose of a smear is `at the expense of fidelity to UTC during the smear window` and uses MUST NOT to prohibit smearing on public-facing NTP servers and mixing servers that smear with servers that do not. ⇒ This is the first time smear appears explicitly in an IETF document, but it was not standardized; rather, the document limits the circumstances under which it may be used. The verbatim text is placed in a later section. References: RFC 8633
2020	`BIPM`	`Adopted`	BIPM and ITU signed a memorandum of understanding. Resolution 655 (Rev.WRC-23) refers to the memorandum of 2020 in recognizing e), and Resolution 4 of the 27th CGPM welcomes its signing. ⚠ This record only includes the year, as the exact date of the memorandum and its signing have not been verified. ⇒ This memorandum is the premise of the division of roles from 2022 onward, in which the CGPM decides the upper limit on the UT1-UTC difference and the ITU-R endorses it. References: Resolution 4 of the 27th CGPM (2022) / Resolution 655 (Rev.WRC-23)

2022-2023 - The CGPM Decides, and the ITU Endorses

During this period, a decision to change the upper limit on the UT1-UTC difference was adopted on the metrology side, and the telecommunications side then endorsed it. Separate bodies made these two decisions, and they reference each other.

Date	Who	Type	Summary
2022-11	`CGPM`	`Adopted`	Resolution 4 of the 27th CGPM decided that the upper limit of the difference between UT1 and UTC will be increased in or before 2035. The meeting took place from November 15 to November 18, 2022. The resolution stipulates `decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035,` and also requests that the CIPM propose a new upper limit, an implementation plan, and a review period, to be presented as a resolution at the 28th CGPM (2026). ⛔ This resolution did not abolish leap seconds. It decided to change the upper limit and left the value and the date to 2026. The verbatim text and the structure are placed in a later section. References: Resolution 4 of the 27th CGPM (2022)
2022-11-10	`AWS`	`Launched`	Amazon Time Sync Service began offering a public NTP service over the internet. The What's New post gave the smear method in numbers for the first time. It states, `In the event of a leap second, the Amazon Time Sync service automatically handles this for you by smoothing out the addition, or removal, of the leap second with a 24-hour linear smear from noon to noon UTC.` ⇒ AWS's own document confirms that it is the same 24-hour linear smear that Google recommends. References: Amazon Time Sync is now available over the internet as a public NTP service
2023-07-28	`CCTF`	`Published`	BIPM announced the establishment of a CCTF task group to address progress towards a continuous UTC. The news item states that the CCTF's strategic planning working group established the task group in May 2023, and that its mission is to prepare a draft resolution, including the new tolerance value and the implementation date, for the 28th CGPM. ⚠ The task group was established in May; the announcement came in July. This article places the row on the announcement date. References: Establishment of a CCTF Task Group to address progress towards a continuous UTC
2023-10	`CIPM`	`Adopted`	The CIPM recorded the projection that a negative leap second would be needed before 2035 and asked the CCTF to examine bringing the date forward. Decision CIPM/112-14 (2023) reads: `The CIPM noted that the trend projected by the International Earth Rotation and Reference Systems Service (IERS) would lead to a negative leap second for the first time before 2035 and asked the CCTF to identify the best way forward and the necessary steps to allow a timely application of Resolution 4 adopted by the CGPM at its 27th meeting (2022) working together with the International Telecommunication Union (ITU).` ⇒ The reason for bringing the 2035 ceiling forward first appears in an official document here. ⚠ The list of decisions gives only the year. The month is aligned with the October 2023 meeting referenced by other decisions from the same session. References: Meetings of the CIPM: Outcomes
2023-11-16	`AWS`	`Launched`	Amazon Time Sync Service began offering microsecond-accurate time and PTP hardware clocks. The AWS Compute Blog states, `The new PHC device, however, will not provide a smeared time option.` ⇒ The unsmeared time announced in 2017 was delivered as a PTP hardware clock. The same article recommends against mixing smeared and non-smeared time sources during leap seconds. References: It's About Time: Microsecond-Accurate Clocks on Amazon EC2 Instances
2023-12	`ITU-R`	`Adopted`	WRC-23 adopted Resolution 655 (Rev.WRC-23), endorsing the CGPM's decision from 2022. The meeting took place from November 20 to December 15, 2023. Its resolves 1 reads `that, until the implementation of continuous UTC (see recognizing g)), UTC as described in Recommendation ITU-R TF.460-6 shall continue to apply;` recognizing k) sets the upper limit to `no less than 100 seconds` and resolves 4 sets the transition period for existing equipment to `until 2035, but no later than 2040` ⇒ ITU-R decided not to set the value of the upper limit itself, but to determine the value and the date together with the CGPM. Progress will be reported to WRC-27. References: Resolution 655 (Rev.WRC-23)

2025-2026 - A Draft Resolution Brings the Date Forward, and the Vote Is Still Ahead

The rows of this period are the most recent as of the verification date, and the last row is a scheduled event. Against the ceiling year of 2035, a specific date in 2027 has been proposed. ⛔ The proposal has not yet been voted on.

Date	Who	Type	Summary
2025-10-07	`CCTF`	`Published`	The BIPM published the outcome of the 2025 CCTF meeting and stated that the CCTF agreed to work toward an early implementation of continuous UTC. The news item states: `agreed to work towards a fast implementation of continuous UTC by encouraging international agreement` ⚠ At this point, neither a value nor a date had been published. References: Latest Updates from 2025 CCTF Meeting
2026-01-13	`CIPM`	`Published`	The convocation of the 28th CGPM was issued. The meeting will take place from October 13 to October 15, 2026, in Versailles. Annex 1 lists draft resolutions A through F, and C is On the technical actions needed to ensure the continuity of UTC. ⇒ A draft resolution that changes the handling of leap seconds was thus formally placed on the agenda of the General Conference. References: Convocation of the 28th meeting of the CGPM
2026-03	`CIPM`	`Adopted`	The CIPM approved the update to draft resolution C, fixing the implementation date of the new upper limit as May 20, 2027. Decision CIPM/115-5 (2026) states that the CIPM endorsed the CCTF's update to draft resolution C for presentation to the 28th CGPM, and that the update fixes May 20, 2027, as the implementation date. The verbatim text is placed in a later section. ⚠ The list of decisions gives only the year. The month is aligned with a reference on the same page to Decision CIPM/115-3 as an agreement from March 2026. ⛔ This is an approval by the CIPM, not a vote by the CGPM. References: Meetings of the CIPM: Outcomes
2026-06-30	`AWS`	`Launched`	Microsecond-accurate time from Amazon Time Sync Service reached 26 more EC2 instance types in all commercial regions through precision time placement groups. ⇒ The range of instances that can read the unsmeared PTP hardware clock has widened to this extent as of the verification date. This article does not cover the design of placement groups. References: Amazon Time Sync Service adds support for Microsecond accurate time on 26 additional EC2 instance types in all commercial regions
2026-07	`CCTF`	`Published`	The CCTF published the report accompanying draft resolution C. The report considered three options for the upper limit: one minute (about a century of continuity), one hour (about a millennium), and no upper limit. It proposes one hour. The report states that the probability of a negative leap second was estimated at about 30% within the next ten years at a workshop held by the BIPM and the IERS in 2025, and concludes that `UTC should be made continuous by 2027.` ⚠ The probability figures are the report's statements, and this article has not verified the estimates. References: Report from the CCTF on Draft Resolution C
2026-07-06	`IERS`	`Announced`	Bulletin C 72 announced that no leap second will be inserted at the end of December 2026. The bulletin states: `NO leap second will be introduced at the end of December 2026.` The difference between TAI and UTC remains at 37 seconds, as it has since January 1, 2017. ⇒ This is the latest announcement in effect as of the verification date. The next issue will be published in January 2027. References: Bulletin C 72
2026-10-13	`CGPM`	`Scheduled`	The 28th CGPM is scheduled to convene, and draft resolution C is to be put to a vote. The meeting will take place from October 13 to October 15, 2026. ⛔ The verification date of this article precedes this session, so the result of the vote is not in this article. The content of the draft resolution is placed in a later section. References: 28th meeting of the CGPM

Every Leap Second Inserted So Far (27 Rows from 1972 to 2016)

A total of 27 leap seconds have been inserted to date, and all have been positive. A negative leap second has never been inserted. The following three tables split the records of the IERS's Leap_Second.dat and UTC-TAI.history by era. The announcement column gives only the Bulletin C issues whose text this article checked; the other rows rest on the data files alone. The insertion dates are UTC dates, the days whose final minute had 61 seconds.

1972-1979 - Nine Insertions in Eight Years

Inserted at the end of	TAI-UTC after	Announcement checked	Note
1972-06-30	11 s	Data files only	The first leap second
1972-12-31	12 s	Data files only	The only year with two insertions
1973-12-31	13 s	Data files only
1974-12-31	14 s	Data files only
1975-12-31	15 s	Data files only
1976-12-31	16 s	Data files only
1977-12-31	17 s	Data files only
1978-12-31	18 s	Data files only
1979-12-31	19 s	Data files only

References: Leap_Second.dat / UTC-TAI.history / tai-utc.dat

1981-1998 - Thirteen Insertions in Eighteen Years

Inserted at the end of	TAI-UTC after	Announcement checked	Note
1981-06-30	20 s	Data files only	Start of the period of end-of-June insertions
1982-06-30	21 s	Data files only
1983-06-30	22 s	Data files only
1985-06-30	23 s	Data files only
1987-12-31	24 s	Data files only	The day before the IERS began operations
1989-12-31	25 s	Data files only
1990-12-31	26 s	Data files only
1992-06-30	27 s	Data files only
1993-06-30	28 s	Data files only
1994-06-30	29 s	Data files only
1995-12-31	30 s	Data files only
1997-06-30	31 s	Data files only
1998-12-31	32 s	Data files only	No leap second followed for seven years

References: Leap_Second.dat / UTC-TAI.history / tai-utc.dat

2005-2016 - Five Insertions After a Seven-Year Gap

Inserted at the end of	TAI-UTC after	Announcement checked	Note
2005-12-31	33 s	Bulletin C 30 (Paris, 4 July 2005)	The first insertion in seven years
2008-12-31	34 s	Bulletin C 36 (Paris, 4 July 2008)	The first leap second that Google smeared
2012-06-30	35 s	Bulletin C 43 (Paris, 5 January 2012)	The leap second around which the Linux kernel timer fixes entered
2015-06-30	36 s	Bulletin C 49 (Paris, 5 January 2015)	The leap second for which AWS announced smearing on its managed services
2016-12-31	37 s	Bulletin C 52 (Paris, 6 July 2016)	The last leap second as of the verification date

References: Bulletin C 30 / Bulletin C 36 / Bulletin C 43 / Bulletin C 49 / Bulletin C 52 / Leap_Second.dat

⇒ Out of 27 instances, the end of June was used 11 times, and the end of December was used 16 times. The end of March and September were never used. The guide to the IERS Bulletin C states, Since the system was introduced in 1972 only dates in June and December have been used. Only the two months given first preference in TF.460-6 have been used. ⚠ The intervals between insertions are not consistent. From 1972 to 1979, an insertion occurred every year, and from 1999 to 2005, there was a seven-year gap. Leap seconds are not a periodic adjustment; the IERS decides each one based on observations of the Earth's rotation.

What Breaks in a Computer When a Second Is Inserted

This section does not list specific failures. Instead, it divides what a leap second breaks in a computer into five types, and attaches primary records to each. The five types correspond to the table of what a computer reads in an earlier section. In each case, the breakage arises not from carelessness of implementers, but from a place where the definition of UTC and the definition of computer time disagree.

A Smeared Clock and an Unsmeared Clock Around a Leap Second

Type 1 - The Second That Cannot Be Represented

UTC includes a 23:59:60 second. TF.460-6 defines a positive leap second as the second that begins at 23h 59m 60s and ends at 0h 0m 0s of the following day. In contrast, POSIX's seconds since the Epoch always counts a day as having 86,400 seconds. There is no corresponding value for the 61st second.

Google Cloud's documentation describes how Unix-based operating systems have handled this discrepancy.

Leap seconds for a Unix operating system are commonly implemented by repeating the last second of the day.
This can cause problems with software that expects timestamps to only ever increase.

Windows also officially documents how it handles seconds that cannot be represented. Microsoft Learn's "Support for the leap second" states:

Therefore, 2012/7/1 08:59:60 is processed as 2012/7/1 09:00:00, per the ISO 8601 format.

The same document notes that SQL Server's date type does not accept a value of 60 seconds, and that passing this value from an operating system that supports leap seconds will result in an error. ⇒ This type of breakage is not a defect of implementations that do not know about leap seconds. Rather, UTC, which has leap seconds, and the computer's definition of time, which does not, disagree for that one second only. To date, there have been 27 days on which the number of seconds in a Unix timestamp does not match the number of UTC seconds elapsed.

Type 2 - Time That Goes Backward

If an implementation chooses to repeat one second, as in the previous type, the wall clock moves back by one second. The man-pages state that CLOCK_REALTIME is affected by discontinuous jumps. Cloudflare's post-incident analysis from 2017 provides a primary record of this type.

The root cause of the bug that affected our DNS service was the belief that time cannot go backwards.

The post-incident analysis details that Go's time.Now() did not guarantee monotonicity at the time, and that calculations would halt when the difference between two timestamps became negative. It writes the lesson as follows:

One precaution when using a non-monotonic clock source is to always check whether the difference between two
timestamps is negative.

⇒ This type lurks in every place that uses time as a difference. Measuring elapsed time, implementing timeouts, enforcing rate limits, and ordering log entries all rely on calculating the difference between two timestamps. Code that does not account for the wall clock moving backward is tested on that assumption for the first time on the day of a leap second.

Type 3 - The Kernel Is Told, but the Timers Are Not

NTP uses the Leap Indicator to warn of a leap second, and the kernel applies it at the end of the month. However, there are several mechanisms within the kernel that rely on time, and it's not guaranteed that notifications of these adjustments will reach all of them. Two commits in the Linux kernel from 2012 are the primary records of this type.

The March commit addressed an issue where the use of hrtimers in applying leap seconds could lead to livelock. ⚠ The fix entered a little more than three months before the leap second. Following the leap second on June 30, the July commit addressed a different path.

The timekeeping code misses an update of the hrtimer subsystem after a leap second happened. Due to that
timers based on CLOCK_REALTIME are either expiring a second early or late depending on whether a leap
second has been inserted or deleted until an operation is initiated which causes that update.

The commit description states that a workaround of resetting the time had been reported, and uses the fact that this workaround triggers the hrtimer update to explain the cause. ⇒ The leap second itself was applied correctly; the problem was that certain mechanisms were not informed of its application. This type of issue can occur even in operating systems that claim to handle leap seconds correctly.

Type 4 - Two Sources That Disagree Inside the Smear Window

Leap-smeared time and time that inserts the leap second as a step differ inside the window around the leap second. RFC 8633 states that this difference can reach as much as a full second, depending on the implementation.

During the adjustment window, all the NTP clients' times may be offset from UTC by as much as a full second,
depending on the implementation.

With the 24-hour method recommended by Google, the difference changes sign at the exact moment of the leap second, and the magnitude stays just under 0.5 seconds. Google's leap smear page states:

At the beginning of the leap second, smeared time is just under 0.5 s behind UTC. UTC inserts an additional
second, while smeared time continues uninterrupted. This causes smeared time to become just under 0.5 s
ahead of UTC when the leap second ends.

⇒ Both time sources are correct according to their own definitions. The smeared time progresses according to the smear definition, while UTC inserts one second as specified in TF.460-6. The discrepancy arises when a single client reads both sources simultaneously. RFC 8633 prohibits this, and both AWS and Google include similar warnings in their own documentation. The verbatim text is provided in the following section. The situation described earlier, where the logs of the two services differ by 1 second, may fall under this type. Both clocks are accurate, yet they display different values at the same instant.

Type 5 - The Clock That Never Had a Leap Second

TAI, and the reference clocks that RFC 7164 classifies as Non-leap-second-bearing, do not have leap seconds. To obtain UTC from a clock that has no leap seconds, the current integer-second difference must be subtracted. The difference is 37 seconds as of the verification date, and the Linux description of CLOCK_TAI reads as follows.

It counts seconds since 1970-01-01 00:00 TAI (1969-12-31 23:59:50 UTC), so its epoch is ten seconds before
CLOCK_REALTIME's.

⇒ This type of failure occurs when the value 37 is embedded as a constant. The value 37 can change each time the IERS announces it in Bulletin C; it went from 36 to 37 on 2017-01-01. The understanding that a clock without leap seconds frees a system from the leap second problem is only half correct. While it avoids the step caused by the leap second itself, the value used to convert to UTC still depends on the body that announces leap seconds.

Leap Smearing - What It Trades Away

What a Smear Does to the Length of a Second

Leap smear is a method that, instead of inserting the second as a step, spreads that one second thinly across the time before and after the leap second. This approach, recommended by Google and adopted by AWS, linearly distributes the second over the 24-hour period from noon to noon the following day. Google's page describes the change in rate as follows.

The long duration keeps the frequency change small. The change for the smear is about 11.6 ppm.

An AWS blog post from 2015 describes the same concept, stating that every second becomes 1 plus 1/86,400 times as long. ⇒ A smear changes the length of a second. The 86,400 seconds that the computer counts inside the window are each slightly longer than an SI second. This point is stated as it is in a document from the metrology side. Draft Resolution C for the 28th CGPM notes this.

the use of different mitigation methods for leap second introductions by global service providers in their
server systems, in order to avoid time steps, leads to inconsistency in timing between different systems
and in the disseminated time and frequency, which do not conform to the SI unit,

Smeared Time Is Not UTC

RFC 8633, as BCP 223, defines the purpose and the limits of leap smear. The purpose is stated in the following sentence.

The purpose of leap smearing is to enable systems that don't deal with the leap-second event properly to
function consistently, at the expense of fidelity to UTC during the smear window.

Concerning its limitations, three constraints are outlined in sequence. The first constraint applies to operators for whom synchronization with UTC is legally required.

Operators who have legal obligations or other strong requirements to be synchronized with UTC or civil time
SHOULD NOT use leap smearing because the distributed time cannot be guaranteed to be traceable to UTC
during the smear interval.

The second constraint applies to publicly accessible NTP servers.

Leap smearing MUST NOT be used for public-facing NTP servers, as they will disagree with non-smearing
servers (as well as UTC) during the leap smear interval, and there is no standardized way for a client to
detect that a server is using leap smearing.

The third constraint applies to client configurations.

Individual clients MUST NOT be configured to use a mixture of smeared and non-smeared servers.

⛔ Smeared time is not UTC. Outside the window it agrees with UTC; inside the window it diverges. With Google's 24-hour method, the size of the divergence is just under 0.5 seconds. A Microsoft article from 2018, citing a 2018 paper by NIST and USNO, stated that smear introduces an error of roughly plus or minus 0.5 seconds against the UTC definition, which is why Windows Server 2019 does not offer the option to use smear. ⇒ Choosing to smear means trading the step at the moment of the leap second for a departure from UTC inside the window. RFC 8633 writes what is traded, and each provider decides which to choose.

No Standards Body Defines the Smear

None of the documents of the four bodies cited in this article defines smear. TF.460-6 only defines the leap second step, and the CGPM resolutions do not define smear. RFC 8633 addresses smear, but it only limits where it may be used and does not standardize the method. The specification of a smear is found only in the documentation of each provider.

Resolution 4 of the 27th CGPM records this state as it is in its noting clause.

operators of digital networks and GNSSs have developed and applied different methods to introduce the leap
second, which do not follow any agreed standards,

⇒ The variety of methods that providers built to avoid the leap second is cited on the metrology side as one reason for changing the upper limit on the UT1-UTC difference. Google, on its own page, proposes the 24-hour linear smear as a recommended standard and states, Amazon uses this smear in AWS. However, this is a recommendation from Google, not a document from a standards body. Therefore, whether a provider smears, and in which window, can only be verified in that provider's official documentation. The following section does this for three providers.

How Each Cloud Provider Handles Leap Seconds

This section describes how three cloud providers handle leap seconds, based solely on their official documentation. No ranking is given. The verification date is September 12, 2026 for all three. ⛔ This article does not extend one provider's statement to the others. The generalization that cloud providers in general smear leap seconds cannot be derived from any of the three providers' documentation.

AWS - Smeared over NTP, Not Smeared over the PTP Hardware Clock

AWS maintains multiple time sources, and each handles leap seconds differently. The EC2 User Guide's section on Leap Seconds states:

To support this transition, we still plan on smearing time during a leap second event when accessing the
Amazon Time Sync Service over the local NTP connection or our public NTP pools (time.aws.com). The PTP
hardware clock, however, does not provide a smeared time option. In the event of a leap second, the PTP
hardware clock will add the leap second following UTC standards. Leap-smeared and leap second time sources
are the same in most cases. But because they differ during a leap second event, we do not recommend using
both smeared and non-smeared time sources in your time client configuration during a leap second event.

The same User Guide's configuration page summarizes this under "Considerations":

The NTP time source offers a leap smearing view of the UTC timescale, while the PHC does not smear time.

AWS Time Source	Leap Second Handling	Source
Amazon Time Sync Service (local NTP)	Smears	EC2 User Guide
Public NTP (time.aws.com)	Smears. Linear over 24 hours, noon to noon	What's New (2022-11-10)
PTP Hardware Clock (Linux, precision time placement group)	Does not smear. Inserts the leap second following UTC	EC2 User Guide
Clocks on AWS managed services	Distributed over 24 hours for the 2015 leap second	Official AWS Blog (2015)

⛔ Do not infer that the PTP hardware clock is vulnerable to leap seconds. AWS states two things: that the two time sources differ only during a leap second event, and that both should not be used at the same time. AWS does not indicate which time source is superior.

⚠ AWS also addresses the future of leap seconds, but its wording is not the same as the CGPM resolution's. The User Guide states,

Leap seconds are going away, and we are in full support of the decision made at the 27th General Conference on Weights and Measures to abandon leap seconds by or before 2035.

However, CGPM Resolution 4 does not state that leap seconds will be abolished; instead, it says that the upper limit of the difference between UT1 and UTC will be increased in or before 2035. AWS's sentence is a paraphrase of the resolution, not the wording of the resolution. This article places both as they are and distinguishes whose words they are.

Google Cloud - Smeared, With a Warning Not to Mix

Google has been smearing in its own services since 2008 and publishes the 24-hour linear smear as its recommended method. The Compute Engine documentation states that its internal NTP service spreads one second over the 12 hours before and the 12 hours after the leap second, and warns against mixing it with external NTP as follows.

We strongly recommend that you don't use external NTP sources with your compute instances. If you use both
Google's NTP service and an external service, you can cause unpredictable changes in the system time.

The same documentation also notes that external, publicly available NTP services often insert leap seconds as a step, which can result in instances observing repeated timestamps. It further states that Google Public NTP provides the same smear as Compute Engine. ⇒ Google's documentation puts its weight on not mixing, rather than on whether to smear. This is the same content as the MUST NOT in RFC 8633.

Microsoft - Windows Inserts the Second and Does Not Smear

Microsoft's documentation explains leap seconds across two layers: the operating system and the time synchronization service. Windows Server 2019 and Windows 10 October 2018 Update handle leap seconds within the platform. Microsoft Learn's "Support for the leap second" states:

Windows Server 2019 and Windows 10 October 2018 Update do support leap seconds in the platform.

The official blog post from 2018 states that this support adheres to UTC, handles both positive and negative leap seconds, and does not include a smear option. Regarding older operating systems, the same Learn documentation explains:

Windows Time Service does not implement a leap second even though it passes through the Leap Indicator (LI)
flag from the NTP server to the server that hosts the Windows Time Service and the down-level clients that
synchronize from it.

⇒ On older operating systems, a difference of about one second from the upstream NTP server arises immediately after the leap second and is corrected at the next synchronization. This is neither a smear nor a step insertion; it is a third behavior, in which the system ignores the leap second and catches up afterwards.

⛔ Microsoft's official documentation does not state whether Azure's host time source smears leap seconds. The documentation for Azure Linux VMs states that the hosts synchronize with Microsoft's Stratum 1 time servers, and that newer Linux images read the host's PTP device using chrony, but it does not mention leap seconds. The corresponding documentation for Windows VMs only says that external time servers can be useful for handling leap seconds in a special way. This article does not write that Azure does not smear. It writes that the official documentation does not state it.

What the Three Statements Have in Common

The three documents share a common structure, despite their differences in approach.

They each separately describe what the platform's time source does and what the guest OS reads. AWS explicitly states that the EC2 instance's clock belongs to the user. Google asks that instance NTP settings point at its internal service, and Microsoft covers OS support and the Azure host in separate documents. ⇒ That a provider smears does not by itself mean that the reader's instance is reading smeared time.
The two providers that smear publish the same window. Both AWS and Google use a 24-hour linear smear, from noon to noon. However, this alignment between the two documents is coincidental and not a defined standard.
All three providers write on the premise that two time sources differ during a leap second. AWS and Google warn against mixing them, while Microsoft explains that older operating systems will correct an approximately one-second difference during the next synchronization. ⇒ The two providers that smear foresee the Type 4 breakage in their own documentation. What Microsoft documents is a disagreement that has no smear window.

⚠ That the three providers differ in method does not mean that any one of them is wrong. RFC 8633 permits smearing with limits, and TF.460-6 defines a step. Both are primary sources. What is important for the reader's design is to verify, through the official documentation of each time source in their environment, which option each time source selects.

The End of Leap Seconds - Decided, Proposed, and Open

The future of leap seconds mixes what has been decided, what has been proposed but not decided, and what remains undecided. ⛔ Many secondary articles condense all three of these into a single sentence stating that leap seconds have been abolished. This article will break down the situation by document.

What the 27th CGPM Decided in 2022

Resolution 4 of the 27th CGPM begins by recalling the procedure for leap seconds in its recalling clause.

when the difference (UT1-UTC), as observed by the International Earth Rotation and Reference Systems
Service (IERS), is predicted to approach 0.9 seconds, a leap second is applied according to the procedure
described in Recommendation ITU-R TF.460-6 of the International Telecommunication Union Radiocommunication
Sector (ITU-R),

Its noting clause lists that the discontinuities of leap seconds risk causing serious malfunctions in critical digital infrastructure, and that operators insert leap seconds by methods that do not follow any agreed standards, and then says the following about a negative leap second.

recent observations on the rotation rate of the Earth indicate the possible need for the first negative leap
second whose insertion has never been foreseen or tested,

The resolution decided one point:

decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035,

Furthermore, the resolution requests the CIPM to undertake four actions. The first is to propose a new upper limit value.

propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least
a century,

The second is to develop an implementation plan.

prepare a plan to implement by, or before, 2035 the proposed new maximum value for the difference (UT1-UTC),

The third is to propose a review period.

propose a time period for the review by the CGPM of the new maximum value following its implementation, so
that it can maintain control on the applicability and acceptability of the value implemented,

The fourth is to draft a resolution for the 28th CGPM.

draft a resolution including these proposals for agreement at the 28th meeting of the CGPM (2026),

⛔ Three things this resolution did not decide. First, it did not decide the value of the new upper limit. Second, the year 2035 is an upper limit, not an implementation date. Third, it did not address the procedure for inserting leap seconds, as defined in TF.460-6, as that is a document produced by the ITU-R. ⇒ What was decided in 2022 was the policy to change the upper limit, and the plan to decide the value and the date in 2026.

What WRC-23 Decided in 2023

The ITU side endorsed the CGPM's decision in Resolution 655 (Rev.WRC-23) of WRC-23. Resolves 1 and 2 read as follows:

that, until the implementation of continuous UTC (see recognizing g)), UTC as described in Recommendation
ITU-R TF.460-6 shall continue to apply;

that ITU-R cooperate further with BIPM, CIPM and CGPM in response to the consultation in realizing, to
define a new maximum value for the difference between UT1 and UTC and on the implementation date for
continuous UTC, possibly in 2035;

Recognizing k) sets a floor for the upper limit.

that the maximum value for the difference between UT1 and UTC should be no less than 100 seconds, taking
into account the constraints of the technological systems expected to be used to disseminate this value,

Resolves 4 provides a transition period until 2035, or at the latest 2040, for existing equipment that broadcasts the difference between UT1 and UTC. Resolves 5 stipulates that the name UTC will be maintained when TF.460-6 is revised. ⇒ What the ITU-R decided is that the current procedure stays in force until continuous UTC is implemented, that the value and the date are decided together with the CGPM, and that the name does not change. Progress will be reported to WRC-27.

What Draft Resolution C Proposes for October 2026

Draft Resolution C, submitted to the 28th CGPM, proposes two things in its decides.

continuous UTC will become effective on 20 May 2027,

the maximum value for the difference |UT1-UTC| will be 3 600 seconds (1 hour), ensuring the long-term
continuity for UTC for several centuries,

The CIPM approved this update in Decision CIPM/115-5 (2026).

The update fixes 20 May 2027 as the implementation date of the new maximum value for the difference
|UT1-UTC|.

The draft resolution notes that a negative leap second has never been applied and that it poses a high risk to unprepared infrastructures, and refers to the IERS's support in its welcoming clause.

a negative leap second has not previously been applied, and it is considered to pose a high risk of causing
anomalies and disruption to critical infrastructures that are largely unprepared,

the support and engagement of the IERS to take all necessary measures to change its operational provision
for, and its announcement of, leap seconds according to the CGPM resolutions,

The CCTF report considered three options as potential limits: 1 minute, 1 hour, and no limit. It chose the 1-hour option, citing the need for known limits in systems that disseminate the difference between UT1 and UTC, and noting that the choice of time zone leaves some countries with a difference of more than one hour between solar time and civil time, and that daylight saving time introduces a one-hour discontinuity every year. Regarding a negative leap second, the report records an estimated probability of about 30% within the next ten years, and concludes:

UTC should be made continuous by 2027.

⛔ All of these are proposals. As of the verification date, the 28th CGPM has not convened, and no vote has been taken. 2035 is the decided ceiling, and 2027-05-20 is a proposed date. This article does not write the two with the same strength.

What Remains Open as of the Verification Date

The following items remain unresolved and are listed without presenting them as negative assertions.

The outcome of the vote at the 28th CGPM. The session is scheduled for October 13 to October 15, 2026.
Revision of TF.460-6. Resolution 655 (Rev.WRC-23), resolves 3, calls for studies that include a revision, and progress will be reported at WRC-27. The CCTF report states that ITU-R Working Party 7A reached an agreement in March 2026 on methods for updating the code that broadcasts the difference between UT1 and UTC; however, that document is restricted, and this article treats it only as the report's description.
The possibility of a leap second occurring before May 20, 2027. Of the months given first preference by TF.460-6, only the end of December 2026 falls before this date, and Bulletin C 72 announced that no leap second will be inserted then. The end of March, the second preference, remains in the procedure but has never been used since 1972. ⚠ If the draft resolution is not adopted, the premise of this paragraph changes as well.
How NTP Leap Indicators and operating system leap second files will be handled after a continuous UTC is established. This article has not verified any documents that address this. The man-pages state, regarding CLOCK_TAI, that because leap seconds are planned to be discontinued, its offset from CLOCK_REALTIME will likely remain exactly 37 seconds for many years; however, this is the man-pages' outlook, not a decision.
AWS's wording. The user guide's "Leap Seconds" section uses the terms "2035" and "abandon." If draft resolution C is adopted, the wording of this section becomes a freshness item.

What Changes and What Does Not for a Distributed System

What has not changed as of the verification date is as follows. The leap second system is alive, TF.460-6 is in effect, and Bulletin C is published every six months. The difference between TAI and UTC is 37 seconds. According to each provider's official documentation, AWS and Google smear, and Microsoft does not provide a smear. As long as leap seconds are possible, the prohibition of mixing specified in RFC 8633 remains relevant. The definition of one day as 86,400 seconds in POSIX remains unchanged, regardless of the presence of leap seconds.

What may change once the draft resolution is adopted and the implementation date arrives is as follows. If the insertion of leap seconds stops, the difference between TAI and UTC will remain at 37 seconds. The difference between UT1 and UTC will open over centuries toward the ceiling of one hour. Users who need UT1 will obtain the difference from GNSS navigation messages and IERS services. ⚠ These follow from the wording of the draft resolution, not from the result of a vote.

For the reader's design, four questions can be checked as of the verification date. Each has its answer in the primary sources this article cites.

Which row of the table in the section on what a computer reads does each component read? Is it a POSIX second, CLOCK_TAI, a smeared NTP, or a non-smeared PTP hardware clock?
Is any single client reading both a smeared and a non-smeared time source simultaneously? RFC 8633 explicitly prohibits this, and AWS and Google also issue the same warning.
Does the system hardcode the difference between TAI and UTC? The value 37 comes from Bulletin C, and the IERS can change it.
Does the platform in use declare that it can handle a negative leap second? TF.460-6 defines a negative leap second as 23h 59m 58s being followed one second later by 0h 0m 0s, and Microsoft states that it supports both positive and negative leap seconds. For other environments, consult the official documentation for that environment.

Frequently Asked Questions about Computer Time and Leap Seconds

Who decides whether a leap second is inserted?

It is the IERS. Annex 1 of TF.460-6 stipulates that the IERS decides and announces the introduction of a leap second, with announcements to be made at least 8 weeks in advance. This announcement is published in Bulletin C, which is released every six months. ⛔ Neither the CGPM nor the BIPM decides individual leap seconds. In the BIPM's explanation as well, UTC is obtained from TAI by inserting leap seconds on the advice of the IERS.

Who decided that leap seconds will end?

The CGPM made that decision. Resolution 4 (2022) of the 27th CGPM decided that the upper limit of the difference between UT1 and UTC will be raised in or before 2035. The ITU-R, in Resolution 655 (Rev.WRC-23) of WRC-23, endorsed this decision and decided to continue applying TF.460-6 until continuous UTC is implemented. ⚠ The IERS is not the decision-making body. Draft resolution C records, in its welcoming clause, the IERS's support for changing its operational provision and announcement of leap seconds according to the CGPM resolutions.

Have leap seconds already been abolished?

No. As of the verification date of September 12, 2026, the TF.460-6 procedure regarding leap seconds remains in effect, and the IERS has announced in Bulletin C 72 that no leap second will be inserted at the end of December 2026. What has been decided is the 2022 decision to raise the upper limit in or before 2035. The proposal to implement continuous UTC on 2027-05-20 is scheduled for a vote at the 28th CGPM in October 2026, and the verification date of this article is before that vote.

Is smeared time UTC?

No. RFC 8633 states that the purpose of smearing is to let systems that cannot handle the leap second properly run consistently, and that the price is fidelity to UTC inside the smear window. Google's page states that smeared time is just under 0.5 seconds behind UTC at the start of the leap second and just under 0.5 seconds ahead at its end. Outside the window, they agree. For operators with a legal requirement of traceability to UTC, RFC 8633 marks smearing as SHOULD NOT.

Does AWS smear leap seconds?

The behavior depends on the time source. If Amazon Time Sync Service is read over the local NTP or the public NTP, the time is smeared, linearly over 24 hours from noon to noon. The PTP hardware clock is not smeared; it inserts the leap second following UTC. ⛔ AWS recommends against using both time sources at the same time during a leap second event. It does not specify which is preferable.

Does Windows smear leap seconds?

No. Windows Server 2019 and Windows 10 October 2018 Update insert leap seconds in a way that adheres to UTC, and Microsoft explicitly states that it does not offer a smear option. Earlier operating systems cannot represent a seconds value of 60, and their Windows Time Service does not insert leap seconds, instead correcting for an approximate 1-second difference during the next synchronization. ⚠ Microsoft's official documentation does not describe how the Azure host time source handles leap seconds.

Is a Unix timestamp the same as UTC?

No. POSIX.1-2024 defines that, in seconds since the Epoch, each day shall be accounted for by exactly 86,400 seconds, but it leaves the relationship to actual UTC unspecified. On 27 days when leap seconds are inserted, the number of seconds elapsed in UTC is one second greater than the Unix timestamp value. The existing tool Unix Timestamp Converter Tool handles the conversion between Unix timestamps and calendar days.

How many seconds is TAI ahead of UTC right now?

It is 37 seconds. Bulletin C 72 states that, from January 1, 2017, until further notice, the value of UTC minus TAI is minus 37 seconds. The initial value was 10 seconds, and since all 27 leap seconds have been positive, the result is 37 (10 + 27). ⚠ This value may change based on announcements from Bulletin C. This article was last verified on September 12, 2026.

Can a negative leap second happen?

Yes, the procedure allows it. TF.460-6 defines a negative leap second as 23h 59m 58s being followed one second later by 0h 0m 0s of the first day of the following month. However, one has never been inserted to date. In 2023, the CIPM recorded that the trend projected by the IERS would require the first negative leap second before 2035, and draft resolution C cites avoiding that risk as the reason for bringing the date forward. Microsoft has stated that Windows Server 2019 supports both positive and negative leap seconds.

Which document should a design document cite for each claim about time?

It depends on the type of claim. The definitions of seconds, TAI, and UTC are specified in resolutions from the CGPM. The procedure for inserting leap seconds is in TF.460-6. The dates of individual leap seconds and the difference between TAI and UTC are in the IERS Bulletin C. Whether a time source smears, and by which method, is in the official documentation of the provider of that time source. ⛔ It is not possible to cite a single source for all four of these. The timeline in this article indicates which of these sources each row refers to, using the "Who" column.

Summary

This article presents a timeline of the bodies that have decided the second, UTC, and leap seconds, from TAI's origin on January 1, 1958, to the 28th CGPM scheduled for October 13, 2026 (45 rows), and the 27 leap seconds inserted between June 30, 1972, and December 31, 2016.

Three key points can be drawn from this:

The question of who decides on leap seconds has two answers. The CGPM and ITU-R established the system, limits, and procedures, while the IERS decides and announces each insertion. ⇒ It was the CGPM that decided in 2022 to change the limit, and it was the IERS that announced that no leap second would be inserted at the end of December 2026.
Leap smear is not defined in the document of any standards body. It is defined only in the documentation of individual providers, and RFC 8633 merely limits acceptable usage. ⇒ Smeared time has a period in which it does not agree with UTC. Whether a provider smears can only be verified in that provider's official documentation.
The end of leap seconds is decided as a year and proposed as a date. 2035 is the ceiling decided by the 27th CGPM, and May 20, 2027, is the date in the draft resolution submitted to the 28th CGPM. ⇒ As of the verification date, the leap second system is still alive.

⇒ When designing time for a distributed system, the first thing to check is not whether the clocks agree. Instead, it is which time scale each component reads, and who states in a document how it behaves at the moment of a leap second. ⛔ The 37-second difference, the smear window, and the 2035 ceiling are all written, as values on the verification date, in the documents of the bodies that decided them.

All information presented in this article was verified as of September 12, 2026. ⚠ Bulletin C is published every six months. The vote at the 28th CGPM ends on October 15, 2026. When referencing this article, be sure to check the verification date, the issues of Bulletin C published after it, and the result of the CGPM.

References:
Tech Blog with curated related content

Written by Hidekazu Konishi