Leap Seconds Going Away in 2035: What Developers Need to Know Now

Opening paragraph

Leap seconds going away in 2035 marks the end of a 50-year compromise between atomic precision and solar timekeeping. In November 2022, the World Radiocommunication Conference voted to eliminate the practice of inserting one-second adjustments to Coordinated Universal Time (UTC), effective 2035. This abolition will redefine how servers track time, forcing developers to audit systems that currently depend on leap-second insertion rules—or that break when one is inserted.

Introduction

Leap seconds seem small: a single extra second inserted roughly every 18 months to keep UTC aligned with Earth's slowing rotation. But that one second has crashed databases, caused distributed-system race conditions, triggered Cloudflare outages in 2017, and left Linux kernel developers scrambling for workarounds. Removing them is actually the radical move.

The 2035 deadline is nine years away, but the engineering lift is significant. You will need to:

• Audit which systems currently rely on leap-second insertion rules (or incorrectly ignore them).
• Understand whether your code uses POSIX time (which has a known leap-second blindness) or proper UTC time libraries.
• Plan for a switchover to a continuous timescale—either a modified UTC with no insertions, or explicit handling via TAI (International Atomic Time).
• Test distributed systems under the new regime, where NTP no longer has to handle mid-second clock jumps.

This article walks through the timeline, identifies real systems that have failed under leap seconds, and gives you a concrete checklist to start planning now—before the deadline surprises you in a production incident.

What Leap Seconds Are (and Why They Exist)

Earth rotates at a variable rate. Atomic clocks measure time with nanosecond precision, but the planet's rotation—the basis of civil time—is gradually slowing due to tidal friction and other factors. Without correction, the solar noon would drift further and further from clock noon over centuries.

A leap second is a one-second adjustment added (or theoretically subtracted, though this has never happened) to UTC to keep it within 0.9 seconds of UT1, the timescale based on Earth's rotation. The IERS (International Earth Rotation Service) announces leap-second insertions roughly six months in advance. The insertion happens at the end of June 30 or December 31 UTC—the timestamp sequence goes:

23:59:59 UTC (Jun 30 or Dec 31)
23:59:60 UTC (the leap second)
00:00:00 UTC (next day)

This works fine in a calendar. It breaks in digital systems that assume Unix time always increments by exactly 86,400 seconds per day.

The 2035 Decision: Why Leap Seconds Are Finally Going Away

In November 2022, the World Radiocommunication Conference agreed to stop inserting leap seconds by 2035. The vote was not controversial among timekeeping authorities, but the engineering reasons matter:

The real problem is UTC-based systems cannot handle leap seconds gracefully. NTP (Network Time Protocol) clients must freeze the clock during insertion or allow it to step backward—both break applications that assume monotonic time. Financial trading systems, database replication, and distributed consensus protocols fail when the clock jumps.

The shift to a continuous timescale—called "UTC-SLS" (UTC with Smoothed Leap Seconds) by some, or simply "continuous UTC" by others—will let time always move forward. Decades of ISO standards, POSIX, and Unix epoch conventions already assume no leap seconds; removing them finally aligns the legal definition of UTC with how most code actually works.

The deadline of 2035 gives stakeholders nine years to migrate critical systems. However, the transition period itself (roughly 2034–2035) will be complex: systems will need to handle both leap-second-aware and leap-second-agnostic code running in parallel.

Current State as of 2026: How Many Leap Seconds Have Been Added?

Since 1972, when leap seconds were introduced, the IERS has inserted 27 leap seconds into UTC as of mid-2026. These insertions roughly follow a pattern of one leap second every 18–24 months, though the interval is unpredictable and depends on Earth's rotation.

The most recent leap second was inserted on December 31, 2016 (UTC). As of 2026, no leap second has been inserted since then—a notably long gap. This actually underscores why the abolition happened: the gap is growing, and the unpredictability of future insertions makes forward planning impossible for long-running systems.

The cumulative difference between UTC and TAI (International Atomic Time, which has no leap seconds) is currently 37 seconds—meaning TAI is 37 seconds ahead of UTC. After 2035, this offset will become constant, eliminating the surprise insertions entirely.

Which Systems Actually Handle Leap Seconds—and Which Don't

Most production systems do not correctly handle leap seconds. Here's the breakdown:

Systems that explicitly handle leap seconds:

• POSIX-compliant operating systems (Linux, BSD, macOS) with kernel leap-second support enabled (a non-default flag in many distributions).
• NTP daemons and GPS receivers that can process leap-second flags from upstream sources.
• Some high-reliability databases like PostgreSQL (when configured with leap-second-aware time libraries).

Systems that are leap-second-blind:

• Most JavaScript engines, including Node.js—JavaScript Date cannot represent the 61st second of a minute.
• POSIX time itself (defined as seconds since the Unix epoch) intentionally omits leap seconds, so code that only uses POSIX timestamps will silently lose the inserted second.
• Most database systems at the application layer (even if the OS kernel knows about the leap second, the query interface often does not).
• Python's datetime module (without special handling).
• Go's time.Time (no leap-second awareness in the standard library).

The real danger is silent incorrectness. A system that neither handles nor crashes on a leap second will simply skip it: a timestamp sequence will jump from 23:59:59 to 00:00:01, losing one second of data with no error message.

Unix Time, POSIX, and the Leap Second Problem

POSIX defines time as the number of seconds since the Unix epoch (January 1, 1970, 00:00:00 UTC), excluding leap seconds. This was a design choice, not a bug: POSIX deliberately omitted leap seconds to keep timestamps simple and monotonic.

As a result, Unix timestamp and epoch time progresses as if leap seconds don't exist. When a leap second is inserted:

• The real UTC time includes the extra second (23:59:60).
• Unix time skips it: the same instant is represented as seconds-since-epoch for 23:59:59 and again for the next second, 00:00:00 (the new day).
• Any application comparing timestamps across the leap-second boundary may get the comparison wrong, or may count the same Unix timestamp twice.

This design was practical in 1988 (when POSIX was finalized) but has become a major source of bugs. After 2035, when leap seconds stop, POSIX time and UTC will finally be in sync—a massive simplification for any code that assumes a one-to-one correspondence between seconds and timestamps.

Distributed Systems and NTP: Why Leap Seconds Break Clocks

Network Time Protocol (NTP) is the standard for synchronizing clocks across the internet. It broadcasts information about leap-second insertions via leap-second flags in NTP packets.

When a leap second is inserted:

1. NTP servers receive an authoritative leap-second flag from their reference clock (GPS, atomic clock, or IERS data).
2. NTP clients see this flag and must decide how to handle it: freeze the clock, step it backward, or skip the second.
3. The behavior varies by OS and NTP implementation. Some systems introduce a 1-second clock step; others briefly halt the clock.

In distributed systems, this becomes catastrophic:

• A database node might apply the leap second 100 milliseconds before another node does, causing the two clocks to diverge for a moment.
• Distributed consensus systems (Raft, Paxos, Zookeeper) may fail if nodes cannot agree on the ordering of events straddling the leap second.
• Message queues and event logs that rely on timestamp ordering may reorder events.

The Cloudflare outage of June 30, 2012 is the canonical example: a leap-second insertion caused kernel timer interrupts to misfire across their load balancers, resulting in a 2-hour partial outage affecting 0.2% of their traffic at peak. Cloudflare's post-mortem became required reading in the industry.

After 2035, NTP will no longer need to broadcast leap-second flags, eliminating an entire class of distributed-system bugs.

Database Timestamps and the 61st Second

Relational databases store timestamps in various formats: Unix time (integer seconds or microseconds), SQL TIMESTAMP types, or custom column types. Each handles leap seconds differently.

PostgreSQL stores TIMESTAMP WITHOUT TIME ZONE as a floating-point count of microseconds since 2000-01-01 (a different epoch than Unix time), and it inherits the OS kernel's leap-second behavior. If the kernel leap-second is applied, PostgreSQL sees the extra second; if not, it skips it silently. This inconsistency is why even UTC-aware systems fail during leap-second insertions.

MySQL does not have explicit leap-second handling. A DATETIME or TIMESTAMP column cannot represent the 61st second; it will either reject the value or silently skip the insertion.

SQLite stores timestamps as text or integers and has no built-in leap-second support—the burden is entirely on the application layer.

The real problem emerges during replication and backup. If a primary database node applies the leap second and a replica does not (because they have different OS configurations or NTP update timings), the replica will diverge. Queries comparing timestamps across the cutover moment may return inconsistent results.

Best practice: storing dates in databases in a leap-second-agnostic format (like Unix microseconds with explicit documentation that leap seconds are not represented) avoids this entirely. After 2035, this will be the only sane approach.

JavaScript Date and Leap Seconds: What's Safe

JavaScript's Date object (used in Node.js and browsers) is fundamentally leap-second-hostile:

• It internally stores milliseconds since the Unix epoch (a POSIX-based timescale that does not include leap seconds).
• The API has no way to represent or access the 61st second of a minute.
• Calling new Date() during the leap-second insertion will return inconsistent timestamps depending on how the OS handles the insertion.

Example: June 30, 2015 leap second (the most recent as of 2026):

If a JavaScript process tries to measure a precise interval straddling the leap second:

const before = Date.now();  // 1435708799999 ms (23:59:59.999 UTC)
// OS inserts leap second here
const after = Date.now();   // 1435708800000 ms (00:00:00.000 next day)
console.log(after - before);  // Might be 1 ms, or it might be wrong

The result depends on whether the OS kernel froze, stepped, or skipped the clock.

Safer approach:

• Use a library that explicitly decouples from the OS clock, like moment.js with explicit UTC handling (though moment.js itself has no leap-second awareness either).
• For timing-critical code, use performance.now(), which measures elapsed time relative to a process-local clock and is unaffected by leap-second insertions.
• Store timestamps in the database as a separate Unix epoch integer or ISO 8601 string, never relying on Date's internal representation for persistence.

After 2035, this will still be the recommendation, but the risk of silent data loss during the transition will be eliminated.

The Difference Between UTC and TAI (and Why It Matters)

UTC (Coordinated Universal Time) is the timescale used for civil time—it includes leap-second adjustments to stay aligned with Earth's rotation (UT1).

TAI (International Atomic Time) is a continuous timescale maintained by the IERS. It has no leap seconds and advances uniformly, 86,400 seconds per day, forever. As of mid-2026, TAI is 37 seconds ahead of UTC.

Before 2035, the relationship is simple: TAI = UTC + (current leap-second offset), where the offset changes unpredictably every 18–24 months.

After 2035, the expected change is that UTC will be formally redefined to be continuous (no leap seconds), and TAI - UTC will become a fixed constant, probably 37 seconds but possibly adjusted upward if more leap seconds would have been inserted between now and 2035.

For developers, this matters because:

1. If your system currently uses TAI (rare), you're already leap-second-free; migration is minimal.
2. If your system uses UTC but does not track the leap-second offset, you're safe today (because POSIX time already ignores leap seconds), but you must verify this assumption holds after 2035, when UTC's definition changes.
3. If your system uses GPS time (which is TAI-based with a known offset), you need to ensure your GPS receiver will continue to output the correct time after 2035 when leap-second flags stop being broadcast.

The IERS will announce the exact redefinition of UTC around 2032–2033, giving a 2–3 year lead time before the 2035 switch.

Migration Path: How to Future-Proof Your Code Before 2035

Your migration checklist:

Phase 1: Audit (2026–2027)

• Identify all systems that touch timestamps: databases, message queues, caching layers, observability tools.
• Document which ones explicitly handle leap seconds (check OS kernel config, NTP version, application-level time libraries).
• Run tests during past leap-second insertions (replay June 30, 2015 or Dec 31, 2016 scenarios) to see how your stack behaves.

Phase 2: Baseline (2027–2029)

• Standardize on a single timescale for all timestamps: Unix microseconds (POSIX-based, ignores leap seconds) is safest.
• Remove any application-level leap-second handling code; it will become a liability after 2035.
• Upgrade to latest versions of NTP, Linux kernel, and database systems. Document that leap-second flags will be deprecated after 2035.
• Add explicit tests for the leap-second boundary (even though no insertion is scheduled, the code path should remain tested).

Phase 3: Transition (2033–2035)

• As UTC's formal definition changes, re-baseline your reference systems.
• Test the cutover in staging: run systems through the moment leap-second insertion stops.
• Verify that distributed systems (Kafka, Zookeeper, load balancers, DNS) continue to agree on time ordering.
• Ensure your developer resources and runbooks document that leap seconds no longer exist.

Phase 4: Post-2035

• Simplify time-handling code: you can now assume UTC and TAI differ by a constant.
• Remove conditional leap-second logic from observability pipelines.
• Ensure backups and archives correctly label data as "pre-2035 UTC" vs. "post-2035 UTC" (the definitions differ slightly).

For long-term planning, also review the year 2038 problem and migration and the IANA time zone database to understand the broader ecosystem changes in time handling over the next decade.

Frequently Asked Questions

Will any leap seconds be inserted between now and 2035?

As of mid-2026, no leap second has been inserted since December 31, 2016—a 10-year gap. The IERS has indicated no leap second is currently planned before 2035, but their decisions are made only 6 months in advance. Monitor the IERS website for official announcements.

What happens to existing timestamps after 2035?

Timestamps created before 2035 are not retroactively changed. A timestamp representing June 30, 2015, 23:59:60 UTC (the leap second) will remain valid in archives. Systems reading old data must understand that those timestamps include leap-second adjustments; systems writing new timestamps will use the continuous UTC scale.

Do I need to change my code if I use POSIX time?

Likely not immediately. POSIX time intentionally excludes leap seconds, so your code is probably already leap-second-agnostic. However, you should verify your system does not have OS-level leap-second handling enabled (which could cause inconsistencies during the transition). Document this assumption in your code.

What about JavaScript Date in Node.js?

JavaScript Date will continue to work after 2035; no breaking change there. However, the difference between Date's internal milliseconds and the actual UTC time may shift slightly when UTC's definition changes. For applications that require sub-second precision across the 2035 boundary, plan additional testing.

Will GPS time change in 2035?

No. GPS time is based on TAI and has no leap seconds. GPS receivers will stop broadcasting leap-second flags after 2035, but the time they output will remain continuous. Applications using GPS as a time source will see no disruption.

How do I test leap-second handling today?

Set your system clock to June 30, 2015, 23:59:59 UTC (using date -s on Linux, or a VM snapshot), and inject a leap-second flag into your NTP daemon or kernel (most OSes have a settimeofday() syscall or ntpd option for this). Observe how your application responds.

What does "continuous timescale" mean for UTC?

After 2035, UTC will no longer include leap-second insertions. Instead, it will advance uniformly, like TAI does now. The difference (TAI − UTC) will become a known constant, announced in advance. This makes UTC a "continuous" or "monotonic" timescale—time always moves forward, never backward.

Should I migrate to TAI now?

Unless your system already uses TAI or GPS time, migration is not urgent. TAI is not yet standardized for civil use, and most time libraries do not default to it. After 2035, UTC and TAI will differ by a constant, making conversion trivial. Wait until closer to 2035 unless you have a specific reason (e.g., scientific computing with high precision timing).

Bottom Line

Leap seconds are ending in 2035. This is good news for systems that have suffered from leap-second bugs, but it requires planning. Start by auditing which systems currently depend on leap-second handling, eliminate any application-level leap-second logic, and standardize on Unix epoch timestamps (which already ignore leap seconds). The window to migrate is nine years; waiting until 2034 will create a crunch. Test your distributed systems under the transition now, even though no leap seconds are currently scheduled before 2035, because the actual moment of cutover will stress-test any latent timing assumptions in your code.