All I want for Christmas is a negative leap second

Original Article ↗ Hacker News Discussion ↗

Negative leap seconds and their impact

  • Many think a negative leap second is less disruptive than positive ones: no repeated second, just a “missing” one that often looks like a system pause.
  • Concerns remain: some UNIX timestamps would become invalid, and “UNIX time → UTC” would no longer be infallible; code that assumes every integer second is valid could break.
  • Others argue positive leap seconds are far worse, since they can map one timestamp to two different UTC instants and cause “time going backwards” bugs.

Should we have leap seconds at all?

  • Strong camp: abolish leap seconds for civil time.
    • Humans tolerate hour-level errors via time zones and DST; a few seconds or even minutes over centuries would be irrelevant.
    • Leap seconds are non‑predictable (announced ~6 months ahead), which makes long‑range calculations and offline systems awkward.
  • Counter‑camp: UTC’s raison d’être is to track Earth rotation (UT1) within ~1s; without that, we already have TAI.
    • Some navigation/astronomy workflows assume UT1–UTC stays under 1s; they’d need a replacement broadcast signal if UTC stopped tracking UT1.

Alternatives proposed

  • Use TAI (or TAI+constant offset) for all computing; treat civil/solar time as a pure formatting problem via a database (like tzdb).
  • Stop adding leap seconds to UTC and let countries occasionally adjust time zones by 15–60 minutes when solar noon drifts too far.
  • Regularize adjustments:
    • Fixed-date annual leap seconds (or smearing adjustments) so systems are “well exercised.”
    • Rare leap minutes/hours or once‑per‑century corrections with ceremonial treatment.
  • Make leap seconds first‑class in time formats rather than an awkward special case.

Software, protocols, and monotonicity

  • POSIX/UNIX time is criticized as a design mistake: it pretends days are always 86400 seconds and hides leap seconds, complicating precise intervals.
  • Some protocols (GPS, PTP) sensibly just count SI seconds since an epoch; UTC conversion is separate.
  • Real systems often violate “monotonic clock” promises; language libraries have had to paper over clocks going backwards.
  • A recurring suggestion: internal clocks should be monotonic (TAI‑like), and all leap behavior should live in the conversion layer.

Time zones, DST, and real-world practice

  • Many point out time zones and DST already introduce far larger irregularities (missing/duplicated hours, non‑integer offsets, frequent political changes).
  • tzdb updates multiple times per year; this is seen as a proven mechanism for handling civil‑time changes, in contrast to rare leap seconds that few systems test well.