UTC, Tai, and Unix Time (2001)

Leap seconds: keep them or kill them?

• Many argue leap seconds are unnecessary complexity. Their cumulative effect is tiny over human timescales, and any eventual drift can be handled by rare time‑zone changes.
• Others defend them as a way to keep civil time aligned with Earth’s rotation and human biology, comparing future large corrections to the Julian→Gregorian transition.
• Some see abolishing leap seconds as “ignoring nature”; critics reply that modern life already diverges heavily from natural cycles and that precision users should rely on other timescales anyway.
• There’s disagreement on whether long‑term drift (hours over millennia) matters enough to justify ongoing complexity today.

UTC, TAI, POSIX, and Unix time

• TAI: monotonic atomic time with fixed-length seconds; ideal for logging, ordering events, and high‑precision systems.
• UTC: hybrid linked to both TAI and Earth rotation via leap seconds; good for human “clock on the wall” use.
• POSIX/Unix time: integers that mostly follow UTC but effectively assume 86,400 seconds per day, creating ambiguities on leap‑second days and breaking both “pure seconds since epoch” and “clean calendar” interpretations.
• Several commenters argue everything critical should use TAI internally, with UTC/local time as a presentation layer plus a leap‑second table.

Standards and the 2035 change

• Multiple comments note that international bodies have decided to stop inserting leap seconds into UTC by around 2035.
• Some see this as overdue simplification driven largely by IT; others worry about long‑term desynchronization and foresee future “big bang” corrections (e.g., leap minutes/hours) being worse.

Alternatives and design trade‑offs

• Proposed alternatives include:
  • Leap minutes or rarer, larger adjustments (with debate about “tech debt” and future bugs).
  • Handling leap seconds as first‑class entities, not hidden quirks.
  • Letting time drift and adjusting time zones occasionally instead of UTC.
  • More radical reforms: abolishing DST, abolishing time zones, or redesigning the calendar; these are mostly viewed as unrealistic or harmful despite some perceived simplicity.

Software handling and practical pain

• Real systems often “smear” leap seconds, pause or jump clocks, or ignore them, leading to inconsistent behavior.
• Time zones already require a database; several argue leap seconds should be treated similarly.
• Consensus that timekeeping is surprisingly tricky; incorrect assumptions about UTC behaving like TAI cause many bugs.