What is the "Leap Smear" technique that Google uses to stretch time by milliseconds to avoid "leap seconds"?
(Word count of this article: approximately 9,400 words)
Have you ever seen the time "23:59:60" displayed on your smartphone? The answer is almost certainly "no." However, this "time that should not exist" has been inserted into world standard time a total of 27 times since 1972. This is the "leap second."
A leap second is an adjustment where one second is added (or theoretically subtracted) to Coordinated Universal Time (UTC) to compensate for the discrepancy between the precise time kept by atomic clocks (International Atomic Time: TAI) and astronomical time based on the Earth's rotation (UT1). The Earth's rotation is not constant. In addition to the length of a day increasing by about 2.3 milliseconds per century due to tidal friction, it fluctuates subtly every day due to various factors such as crustal movement, ocean currents, and atmospheric changes.
This "mere one-second" adjustment has become a massive threat to modern digital infrastructure. And the solution Google devised for this threat is a clever technique called "Leap Smear," which stretches time little by little.
Chapter 1: The Chaos Caused by One Second—The Tragedy of 2012
On July 1, 2012, between 23:59:59 UTC and 00:00:00 the next day, one second was inserted. In Japan Standard Time, this was 8:59:60 AM. At this moment, internet services around the world collapsed one after another.
Reddit, LinkedIn, Yelp, FourSquare, Gawker, StumbleUpon—renowned services fell into failure. Reddit reported on its official Twitter that "a Java/Cassandra issue related to the leap second at 5:00 PM (PST) is occurring." Mozilla (the developer of Firefox) also experienced outages. Qantas Airways in Australia even faced a situation where its flight reservation system was down for two hours.
The cause of the failure lay in the Linux kernel's leap second handling. Because Linux cannot directly represent 23:59:60, it inserts a leap second by setting the clock back by one second immediately after 00:00:00. This "reversal of time" triggered a bug related to thread management, causing server CPU usage to spike abnormally. The fact that this defect occurred even in the latest kernel versions speaks to the severity of the situation.
Specifically, a phenomenon occurred where the Linux kernel's hrtimer (high-resolution timer) subsystem would fall into an infinite loop when it detected the reversal of time. The Java runtime environment was also affected, and in many services using the Apache Cassandra database, threads ended up spinning at 100 percent CPU usage. Engineers could only recover by restarting the servers.
Damage continued during the leap second at the end of 2016. At Cloudflare, services were interrupted for several hours immediately after the start of the new year because their DNS servers were designed on the premise that "time never moves backward." The company's technical lead, John Graham-Cumming, acknowledged that the cause was a "situation as if time had been rewound."
In Cloudflare's case, the DNS server code written in the Go language assumed the monotonicity of time. When the one-second rewind caused by the leap second occurred, a panic occurred in the timestamp comparison process, and DNS query processing stopped. In its post-mortem analysis, the company reported that approximately 0.2 percent of global DNS queries were affected. This "mere 0.2 percent" actually meant the failure of millions of DNS requests.
One second. In just one second, the foundation of the internet wavers. This fact vividly demonstrates how our digital society is built on the premise that "time continues to move forward."
Chapter 2: The "Lesson of 2005" Experienced by Google
Google first took this problem seriously during the leap second in 2005. Christopher Pascoe, a Google Site Reliability Engineer at the time, recalled: "During the 2005 leap second, some cluster systems stopped accepting work on a small scale. It didn't affect the site itself or the data, but we wanted to prevent future problems."
In ultra-large-scale distributed systems like Google's, time synchronization is a lifeline. Hundreds of thousands of servers are scattered around the world, processing millions of requests per second. If "what time it is" differs between these servers, data integrity collapses. Email arrival order gets messed up. Database transactions fail. Even search result rankings could become inaccurate.
Google's distributed database "Spanner" provides a strict guarantee called external consistency. This is the guarantee that if transaction A completes before transaction B, A's timestamp will always be smaller than B's. To realize this guarantee, Spanner uses a unique time management system called the TrueTime API. TrueTime expresses the current time not as a single value, but as an interval that includes an error range. Atomic clocks and GPS receivers are installed in each data center, keeping time uncertainty within a few milliseconds.
And Google's services were designed with the philosophy of "refusing to operate if the time is not correct." In other words, if the clock becomes strange even for one second due to a leap second, the system shuts itself down. This is a correct design as a safety device, but it cannot handle the "correct anomaly" that is a leap second.
From the experience of 2005, Google's engineers reached a major conclusion: "Rather than modifying tens of thousands of lines of code and testing thousands of services to handle leap seconds, it is more rational to change the clock itself."
In 2008, Google became the first in the world to implement Leap Smear and deploy it to a production environment. The engineering team at the time described this technique as the "most elegant workaround." This is because they were able to solve the problem solely through infrastructure-level time management without touching any application-layer code.
After the bitter experience of 2005, Google's engineers devised a groundbreaking solution. Its name is "Leap Smear." Literally translated, it means "smearing the leap second."
Chapter 3: How Leap Smearing Works—The Magic of Dividing a Second into 86,400 Parts
The basic idea behind leap smearing is surprisingly simple. Instead of suddenly adding a second, it involves slowing down the clock little by little over a long period, effectively absorbing the extra second without anyone noticing.
Google initially adopted a method of slowing the clock speed by 0.0014 percent over a total of 20 hours, spanning 10 hours before and after the leap second. This 20-hour smear was used for the leap seconds in 2008, 2012, 2015, and 2016.
Later, to ensure compatibility with other major cloud providers like Amazon's AWS, Google transitioned to a 24-hour linear smear. The current method is as follows.
The smear start time is UTC noon (12:00:00) on the day of the leap second, and the end time is UTC noon (12:00:00) the following day. The smearing method is a linear smear spanning 24 hours.
What does this look like in practice? Normally, a day has 86,400 seconds. With leap smearing, each of these 86,400 seconds is stretched by approximately 11.6 microseconds (μs). The calculation is 1 second ÷ 86,400 ≈ 11.574 microseconds. In other words, a "Google second" during the smear period is 0.00116 percent longer than a standard second.
This frequency change is about 11.6 ppm (parts per million). This value falls within the range of fluctuations caused by manufacturing errors or temperature variations in the crystal oscillators found in typical computers (which are around several tens of ppm). It is far smaller than the maximum slew rate of the NTP protocol (500 ppm). In short, even to software monitoring the clock, it just looks like the clock is running a little slow.
Let's look at the progress of the smear. At the moment of the leap second (UTC 23:59:60), Google's smeared clock is about 0.5 seconds behind UTC. Then, UTC performs a jump insertion of one second. As a result, the smeared clock becomes about 0.5 seconds ahead of UTC. It then gradually closes that gap over the remainder of the smear period, perfectly aligning with UTC by noon the next day.
Technically, Google implements leap smearing on its own NTP server cluster (time.google.com). These NTP servers, distributed globally, obtain time directly from Stratum 1 (top-tier) atomic clocks and deliver the time with the smear algorithm applied to clients. Google Cloud users automatically benefit from the smeared time without needing to change any settings.
The beauty of this method is that the clock continues to move forward at all times, both during and outside the smear period. There is no backward movement of time. There is no 61st second. There is no non-existent time of 23:59:60. For Google's servers, the day of a leap second is no different from any other ordinary day.
Within the Google Site Reliability Engineering team, this leap smear is reportedly passed down as "one of the coolest workarounds." This is because this mechanism freed them from the monumental task of inspecting and fixing Google's entire massive codebase.
In fact, Google's codebase is said to span billions of lines. Verifying leap second compatibility across all of it is practically impossible. The "clock-side solution" of leap smearing made this impossible task possible.
Chapter 4: Is Smearing a "False Time"?—Legal and Technical Issues
Leap smearing is not a panacea. During the smear period, Google's clock deviates from UTC by up to about 0.5 seconds. This is a state that could be described as "Google's clock is lying."
Legal issues have also been pointed out. In many countries, billing for communication charges and timestamps for financial transactions are required to be based on "accurate UTC or legal time based on it." Timestamps from a smeared clock are not strictly UTC. In systems where mobile phone call billing is done on a per-second basis, a 0.5-second deviation could theoretically lead to billing inaccuracies.
In the financial industry, this problem is even more serious. In stock trading, a difference of just one millisecond in an order timestamp can change profits by millions of dollars. Firms engaged in high-frequency trading (HFT) manage time in microsecond (one-millionth of a second) increments. For them, a 0.5-second deviation is fatal.
For this reason, many financial institutions maintain their own NTP infrastructure that processes leap seconds accurately without using leap smearing. The U.S. Securities and Exchange Commission (SEC) mandates that exchanges keep timestamp accuracy within 50 microseconds. To meet this standard, exchanges use atomic clocks or GPS time sources directly and do not apply smearing.
There was also the issue that smearing methods were not standardized. During the time Google was using a 20-hour smear, Bloomberg adopted a 2,000-second (about 33-minute) smear, and UTC-SLS adopted a 1,000-second smear, each independently. Mixing NTP servers that use different smearing methods can lead to the absurd situation where the time between servers deviates by up to one second.
To address this issue, Google proposed "24-hour linear smearing" as an industry standard in 2018, and Amazon's AWS adopted the same method. The AWS blog explicitly states that "24-hour linear smearing is the most practical leap second mitigation for cloud environments."
Furthermore, Google has released an open-source library called "unsmear" on GitHub that performs precise conversions between smeared clocks and TAI (International Atomic Time) or GPS time. Using this library, it is possible to convert from smeared time to true UTC, TAI, or GPS time with microsecond precision. The library contains a history of all past leap seconds and smearing methods, allowing for the calculation of the smear amount at any given point in time.
The existence of this library demonstrates that leap smearing is not merely a "trick," but a precisely defined and reversible time conversion.
Google's official documentation states: "Smearing is not a way to vaguely smudge the clock. It is a defined, precise, and reversible conversion."
Chapter 5: The Earth is accelerating—an unexpected reversal
Everything discussed so far has been about "positive leap seconds"—the direction of adding one second of time. Since 1972, all 27 leap seconds have been in the positive direction. Since the Earth's rotation has been slowing down in the long term due to tidal friction, this was assumed to be natural.
However, an anomaly occurred in 2020.
In 2020, the Earth broke the record for the shortest day 28 times since 1960. On July 19, it recorded a rotation period 1.4602 milliseconds shorter than 86,400 seconds. On June 29, 2022, an even shorter day, by 1.59 milliseconds, was observed. For some reason, the Earth's rotation began to accelerate.
The International Earth Rotation and Reference Systems Service (IERS) measures the Earth's rotation speed daily. Its measurement method is Very Long Baseline Interferometry (VLBI), which simultaneously observes radio waves from distant quasars using radio telescopes around the world. This method allows the Earth's rotation angle to be measured with an accuracy of 0.00001 seconds.
According to IERS data, between 2020 and 2022, the average length of a day on Earth became about 0.5 milliseconds shorter than 86,400 seconds. This was a statistically significant change, and it was the moment the necessity of a "negative leap second" became a reality for the first time in recorded history.
The cause of this has not been fully elucidated. Multiple hypotheses have been proposed, including movements in the Earth's inner core, the disappearance of the Chandler wobble (the wobbling of the Earth's axis of rotation), and changes in ocean currents and atmospheric patterns. Interestingly, a paper published in Nature in 2024 by Duncan Agnew of the Scripps Institution of Oceanography points out that the melting of polar ice due to global warming is moving water toward the equator, which acts to slow the Earth's rotation. In other words, without global warming, the Earth would be spinning even faster, and a "negative leap second" might have already been necessary.
Agnew's paper analyzes that the Greenland and Antarctic ice sheets are losing about 280 billion tons of ice per year, and as this water moves into the oceans, the Earth's moment of inertia is changing. Just as a figure skater's rotation slows down when they extend their arms, the rotation slows as mass moves away from the Earth's center. Global warming is creating this effect, counteracting the Earth's natural acceleration.
A negative leap second is an unprecedented event where 00:00:00 comes immediately after 23:59:58—meaning 23:59:59 disappears. Even positive leap seconds have caused such major chaos, so no one knows what kind of impact an unknown operation like "deleting a second" would have.
Meta engineers warned in an official blog post: "The impact of a negative leap second has never been tested on a large scale. It could have a catastrophic effect on software that relies on timers and schedulers."
In fact, many systems do not anticipate a negative leap second. The NTP protocol specification describes how to handle a negative leap second, but it has never been implemented. Database timestamp processing, log file time-series analysis, and cryptographic certificate expiration verification—all of these would execute untested code paths.
If Google's leap smearing were to support a negative leap second, it would apply a smear in the direction of making the clock "faster" by 11.6 microseconds. Using 86,399 SI seconds, it would absorb one second over the 24 hours from noon to noon. In theory, the same logic is applicable, but it has not yet been tested in practice.
Google engineers are reported to be already conducting simulations in test environments in case a negative leap second is announced. However, verification in a production environment is impossible until a negative leap second is actually inserted.
Chapter 6: The end of the leap second—toward 2035
On November 18, 2022, a historic resolution was adopted at the 27th General Conference on Weights and Measures (CGPM) held in France: "To abolish the insertion of leap seconds by 2035."
Dr. Patrizia Tavella, Director of the Time Department at the BIPM, described this decision as "historic." Representatives from 59 member states voted, with the United States and France leading the abolition. Russia requested a postponement to 2040, stating that while it was "not opposed in principle, it needed time for GLONASS to adapt," but 2035 was decided as the compromise.
After the abolition, a discrepancy of "more than one second" between atomic time and astronomical time will be permitted. The specific upper limit is scheduled to be decided at the 28th CGPM in 2026. A leading proposal is to leave it until the discrepancy reaches one minute (predicted to take 50 to 100 years) and insert a "leap minute" at that point.
There were over 10 years of debate leading up to this decision. At the 2012 World Radiocommunication Conference (WRC-12), a proposal to abolish leap seconds was submitted, but no agreement was reached. Astronomers opposed the abolition, emphasizing the link between UTC and astronomical time. However, after the leap second disruptions in 2012 and 2016, the sense of crisis on the information technology side grew.
As of 2025, the decision to abolish this was strongly pushed by tech giants such as Google, Meta, Amazon, and Microsoft. For them, the leap second—which is inserted irregularly, announced only six months in advance, and causes potential failures in every system—was truly a "ticking time bomb."
Meta stated in an official blog post, "The leap second is an unavoidable risk for modern distributed systems, and workarounds like leap smearing are merely stopgap measures. The only fundamental solution is abolition."
According to some estimates, the direct damage a single leap second could cause to the global economy could reach tens of millions of dollars, or in the worst case, up to 100 million dollars. Risks are said to be concentrated in finance, aviation, and large-scale internet platforms.
From 2035 onwards, UTC will follow atomic clocks completely. Astronomers will continue to maintain their own astronomical time scales. However, our daily lives and global digital infrastructure will run on the uniform time kept by atomic clocks.
Final Chapter: Time Marches On—What Leap Smearing Teaches Us
Google's leap smear might at first glance look like an excessive response to a "mere one-second" problem. However, there is a deep insight behind it.
One of the most fundamental premises that modern digital systems rely on is that "time flows uniformly in one direction." Database transaction ordering, consensus algorithms in distributed systems, and expiration dates for cryptographic protocols—all of these assume the monotonic increase of time.
Leap smearing is a technique to protect this premise. By dividing one second into 86,400 tiny fragments and sneaking in 11.6 microseconds at each moment, it prevents the system from sensing an "anomaly." Time continues to move forward constantly.
What this technology protects is not just Google Search or Gmail. It is the countless services running on Google Cloud, servers around the world that reference Google Public NTP, and the daily lives of billions of users beyond them.
What is interesting is that leap smearing is also a prime example of a strategy to avoid "technical debt." If Google had not adopted leap smearing and had instead made its entire codebase leap-second compliant, the cost of that response would have reached tens of millions of dollars. And, for the new threat of a negative leap second, the entire codebase would have needed to be reviewed once again.
Leap smearing showed a way to escape this infinite maintenance loop. It is a design philosophy of "absorbing problems at the system interface." By solving problems at the infrastructure layer without touching the application layer, this philosophy also underlies modern cloud-native technologies such as microservice architectures, service meshes, and serverless computing.
In 2035, if the leap second is truly abolished, leap smearing may finish its historical mission. However, the philosophy of "replacing disruptive changes with a series of imperceptibly small changes" will continue to live on in every aspect of software engineering.
The next time you search on Google, I want you to remember this: the time you are looking at so casually might be a tremendously precise "lie" that Google engineers have been adjusting at the level of one ten-thousandth of a second.
And that "lie" is the very truth that protects the internet around the world.
References
Google Developers "Leap Smear" Official Documentation 2023
Google Cloud Blog "Making every (leap) second count with our new public NTP servers" 2016
International Bureau of Weights and Measures (BIPM) "Leap Second Insertion History" 1972 to 2016
Cloudflare Blog "How and why the leap second affected Cloudflare DNS" 2017
Meta Engineering Blog "It's time to leave the leap second in the past" 2022
Nature journal, Duncan Agnew, "Climate change and leap second timing," 2024
27th General Conference on Weights and Measures (CGPM) resolution document, 2022
GitHub "google/unsmear" open source library, 2018
International Earth Rotation and Reference Systems Service (IERS) "Earth Orientation Parameters data," 2020 to 2024
Amazon Web Services Blog, "Handling Leap Seconds with Amazon Time Sync Service," 2018