Tratamento de Segundos Intercalares em Software

What Is a Leap Second?

The Earth's rotation is not perfectly uniform — it gradually slows due to tidal friction, and occasionally speeds up. To keep UTC (based on atomic clocks) aligned with UT1 (based on Earth's rotation) to within 0.9 seconds, the International Earth Rotation and Reference Systems Service (IERS) occasionally inserts a leap second — an extra second added to the end of a UTC day, making that minute 61 seconds long.

When Does a Leap Second Occur?

Leap seconds are announced about 6 months in advance and always occur at 23:59:59 UTC on either June 30 or December 31. The sequence looks like:

23:59:58 UTC
23:59:59 UTC
23:59:60 UTC   ← leap second (this second exists!)
00:00:00 UTC (next day)

Since 1972, 27 leap seconds have been inserted (all positive — no second has ever been removed). The most recent was December 31, 2016.

Why Leap Seconds Cause Software Failures

  • Unix timestamps ignore leap seconds: The Unix timescale pretends every day has exactly 86,400 seconds. During a leap second, two different UTC moments map to the same Unix timestamp.
  • Operating system confusion: Linux kernels before 3.10 sometimes caused high CPU usage or kernel panics during leap seconds (the famous "leap second bug" that crashed servers in 2012 and 2015).
  • Application crashes: Reddit, Foursquare, LinkedIn, and Qantas experienced outages during historical leap seconds.

Leap Smearing

The modern solution is leap smearing: instead of inserting one abrupt extra second, spread the adjustment over several hours. Google pioneered this approach, slowing clocks by ~1/86400 over 20 hours before and after the leap second:

# Google/AWS/Azure all use leap smearing
# The "leap second" appears as a slightly longer period
# time.google.com, time.cloudflare.com use this approach
# Result: no 23:59:60, no duplicate timestamp — clocks just tick slightly slow

Important: If you mix smeared and non-smeared NTP sources, the difference can be up to 1 second around a leap event — causing consistency issues in distributed systems.

The Future of Leap Seconds

In November 2022, the BIPM voted to abolish leap seconds by 2035. UTC will be allowed to diverge from UT1 up to 1 minute before any correction is applied (likely as a "leap minute" after 2135). This will eliminate the leap second problem permanently — but software must handle the current 27-second TAI-UTC offset regardless.

How to Handle Leap Seconds Safely

  • Use time.google.com or time.cloudflare.com as NTP sources (both smear)
  • Ensure all servers in a cluster use the same NTP source (all smeared or none)
  • For critical systems, test with a leap second simulator
  • Update OS and Java/Go/Rust runtimes — modern versions handle leap seconds correctly