Against the Leap Hour

I was very disappointed to read that our standards body would implement a leap hour. As I understand it the leap-second was an adjustment made everyone so many years to keep atomic time and celestial time from diverging much. This has proven to be operationally difficult so now they are getting rid of it, letting the divergence build over the years, and then in the distant future make one adjustment by one hour to keep it from becoming ridiculous: talk about kicking the can down the road.

The bureaucracy is such that (from a quick search) I was unable to find the actual specification not behind a paywall, but the decision to use a leap hour is clear, and in my view completely unacceptable. The rationale seems to be that any change would require a major software overhaul a la Y2K, but legacy code and continue using UTC (as the APIs should be specified to do already) and move to the new system by choice in the future.

Here’s a quick take on a better system, presented in LLM-written form to convey the idea: if anyone with any influence ever notices it’s easy to write up. The idea is obvious but apparently never considered. Did they over-think it or had nobody with software experience involved?

The Dual-Scale Timekeeping Proposal #

This architecture eliminates mandatory software rewrites, preserves legacy systems entirely, and introduces the celestial scale as a completely opt-in, gradual extension.

• Backward Compatibility & Legacy Protection:
  • Existing APIs, databases, and operating systems continue to use UTC-Atomic by default, exactly as they are currently specified. Zero changes are forced on legacy codebases or embedded systems.
  • The new celestial API extensions are introduced as optional, non-blocking additions with no strict migration deadlines. Applications adopt them only when and if the specific benefits outweigh the engineering cost.
• Opt-In Application Semantics & UI Convenience:
  • Applications choose their native scale based on need. High-speed and digital infrastructure remains anchored to continuous atomic time.
  • For human-facing applications, developers can optionally use the celestial format strictly as a display convenience (e.g., rendering a timestamp in local solar time) or output both, while underlying data structures remain untouched. Most short-lived applications will never need to adopt it.
• Contractual and Future-Dated Logic:
  • Legal and commercial contracts already rely on explicit calendar dates and human-readable context.
  • For future-dated transactions, commitments are recorded with nominal human intent. As the target date approaches, exact observational offsets are applied to map the intent to the precise atomic execution point—rendering the projection perfectly precise when precision matters, while high-precision financial contracts can mandate UTC execution directly from inception.

Comparative Evaluation vs. the CGPM Policy #

Without requiring software changes the comparison is one-sided against this decision.

• Preservation of Human Time Alignment: Allowing civil time to drift will confuse and complicate agriculture, marine navigation, and daily human sense of time, this is an avoidable degradation of civil timekeeping.
• Separation of Concerns: Machines require absolute monotonicity (no jumps, no slips), while humans require solar alignment. Forcing them onto the exact same timeline requires a compromise that satisfies neither perfectly, but this model decouples them cleanly.

Conclusion #

Setting aside institutional inertia, the dual-scale opt-in model is architecturally cleaner and logically superior to letting civil time slip by an hour, because it achieves absolute machine precision without sacrificing the integrity of human solar time.