Skip to content

Instantly share code, notes, and snippets.

@joakim

joakim/leapseconds.md

Last active November 8, 2025 19:29
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save joakim/7453d98b927d3110dec53fc9b7181255 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save joakim/7453d98b927d3110dec53fc9b7181255 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
leapseconds.md

On leap seconds

The problem with leap seconds is not leap seconds, but using UTC for precision purposes.

🤖 TAI ⬌ UTC 🧑

If we instead used TAI for computers and derived UTC for humans, there would be no need to abandon leap seconds and decouple the world's calendars from the rotation of the Earth. With TAI, leap seconds have no effect. They would only appear when displayed to humans in UTC, the problem of leap seconds reduced to a UI issue.

Unfortunately, rather than move towards adopting TAI for computers, there's been a strong push by tech companies to remove leap seconds from UTC for all.1 It would practically make TAI the new time scale for all humans on Earth.

They've got it backwards. TAI was intended for technical purposes, UTC was intended for humans.2

Timestamps are a typical cause of leap second issues. Looking at the status quo, it is easy to see what went wrong.

UTC timestamps are a bad fit for computers:

  • Discontinuous3 – leap seconds and daylight saving time lead to bugs
  • Human-readable – while good for humans, it complicates computation, leading to bugs

POSIX/Unix timestamps are even worse:4

  • Ignores leap seconds – repeated and skipped seconds result in ambiguous values, leading to bugs
  • Inconsistent – it's neither UTC nor a continuous count of elapsed SI seconds5

Two timescales, TAI and UTC, is the most obvious solution:6

  • A strictly monotonically increasing time scale for computers (TAI)
  • That easily converts to and from civil time for humans (UTC)
  • With no leap second bugs

Rather than doing the most obvious thing, they propose to fix the issue by removing leap seconds from UTC. This would, for the first time in human history, decouple the calendar from the rotation of the Earth. Let's not do that.

What if we instead apply their proposed time scale to computers only, and continue to use UTC with leap seconds for human purposes? This would elegantly solve the leap second issue without even touching UTC. And the calendar would remain in alignment with the Earth’s rotation, as it has for over 10000 years.

We should do things right: TAI for computers, UTC for humans. As intended.

I see three ways forward.

  1. Continue to use UTC with leap seconds for human purposes. Introduce their proposed time standard for precision purposes only, with a monotonically increasing time scale based on TAI. Let's call it TI (International Time).7

    🧑 UTC with leap seconds
🤖 TI (UTC without leap seconds)

    Requires substantial effort from the tech industry to refactor systems to use TI under the hood.

  2. Remove leap seconds from UTC, continue using it for all purposes.

    🧑 UTC without leap seconds
🤖 UTC without leap seconds

    It would decouple the calendar from Earth's rotation, causing the time-of-day to slowly drift. For the first time in the history of humanity, the passage of time would no longer correspond to the natural rhythms of our planet. Although not noticable at first, it would eventually grow too large to ignore, becoming an even worse problem for future generations.8

  3. Do nothing.

    🧑 UTC with leap seconds
🤖 UTC with leap seconds

    Not an option, something should be done.

I think #2 is too drastic, irresponsible and unwise. A solution to this problem should not negatively affect those who did not cause it in the first place.

Considering that leap second issues are of a technical nature, caused by poor engineering, I believe that #1 is the most reasonable alternative, and that the tech industry should bear the cost.

As a compromise, DUT1 could be allowed to drift until 2035, giving the industry enough time to implement the transition, without any leap second interruptions. The gap would be closed by successive leap seconds after 2035.

Footnotes

  1. See Facebook's It’s time to leave the leap second in the past. ↩

  2. See Steve Allen's Issues involved in computer time stamps and leap seconds. ↩

  3. Or "continuous with discontinuities", as ISO 8601 puts it (page 2). ↩

  4. See D. J. Bernstein's UTC, TAI, and Unix time and Steve Allen's Unix system time and the POSIX standard. ↩

  5. Future of Leap Seconds (Steve Allen). Quote: Basically, the standard says that POSIX time is UTC, except when it is not. POSIX seconds are nominally SI seconds, but for practical purposes POSIX time counts seconds of mean solar time. ↩

  6. Leap second (Wikipedia). Quote: The most obvious workaround is to use the TAI scale for all operational purposes and convert to UTC for human-readable text. UTC can always be derived from TAI with a suitable table of leap seconds. ↩

  7. "UTC without leap seconds" could be defined as TAI with the UTC epoch (1972-01-01 00:00:00 UTC), easing conversion between the two. TI would be the world's reference time standard from which UTC would be derived. ↩

  8. See Steve Allen's Extrapolations of the difference (TI - UT1). ↩

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment