securitylab_nJuly 9, 2026🇷🇺Translated from Russian

Scientists Consider Replacing Leap Seconds with a Century-Scale 'Extra Hour' to Protect Global Digital Infrastructure from Negative Leap Second Risks

Global timekeeping authorities are preparing a landmark decision that could fundamentally change how the world manages civil time. Instead of continuing to insert occasional leap seconds, they are considering a system that would allow an extra hour to accumulate over hundreds of years before any major correction is needed. The goal is not to lengthen the day but to permanently remove the recurring one-second adjustments that have long destabilized computer systems and may become even more dangerous as Earth's rotation speeds up.

The leap second was first introduced in 1972 to keep Coordinated Universal Time (UTC) aligned with the planet's irregular rotation. While atomic clocks maintain exceptional stability, Earth's spin varies due to internal geological processes, ocean currents, atmospheric conditions, and other factors. When the difference between atomic time and astronomical time grows too large, specialists add a single extra second to the calendar year.

For ordinary users the adjustment is barely noticeable. For digital infrastructure, however, it creates serious problems. Computer systems rely on precise sequencing of events, and an abruptly inserted second has already triggered outages at Meta, Reddit, and Cloudflare. It has also disrupted airline operations and interfered with high-frequency stock trading. As networks and financial platforms operate at ever-higher speeds, their tolerance for non-standard time changes continues to shrink.

Many developers have therefore adopted a workaround known as leap-second smearing, in which the extra second is gradually distributed over a longer interval rather than inserted all at once. While this approach reduces immediate crashes, it creates a new inconsistency: different systems begin operating under slightly different time rules.

No leap seconds have been added since 2016 because Earth's rotation has begun to accelerate. Scientists are now discussing the opposite scenario: if the planet starts to outpace atomic time, the first-ever negative leap second may be required. Removing a second from UTC has never been attempted, and experts have no data on how today's infrastructure would respond.

The risk of a negative leap second prompted the General Conference on Weights and Measures in 2022 to accelerate a review of UTC rules, originally targeting 2035 as the deadline. Updated assessments now indicate that waiting that long could be risky, with the probability of needing a negative leap second before 2035 estimated at approximately 30 percent.

The new proposal under discussion would replace the current one-second corrections with a much larger allowable deviation—potentially an entire hour—between atomic time and Earth's position. This change would push the next major adjustment centuries into the future, effectively ending the era of leap seconds for practical purposes. If approved, the revised rules could come into force as early as 2027.

The International Bureau of Weights and Measures considers the issue urgent. Even a 10 percent chance of a negative leap second is viewed as unacceptable for global digital systems. By removing the most disruptive element before it can trigger unpredictable large-scale failures, authorities hope to safeguard servers, exchanges, aviation networks, and telecommunications infrastructure.

The reform would not completely sever the connection between civil time and Earth's rotation, but it would make that link far more flexible. UTC would continue to rely primarily on atomic clocks, while any accumulated difference with astronomical time would be allowed to grow over decades or centuries. Although humanity may eventually have to address an entire hour of divergence, computer systems would no longer need to prepare for sudden one-second jumps that cause more damage than they appear to.

Related articles

HabrOther

OAuth Authorization Server Built Without Storing User Profiles

The article details the evolution of an OAuth Authorization Server that deliberately avoids storing user profiles, relying instead on external identity providers for authentication. It addresses three core constraints: hundreds of dynamically created isolated APIs, a public SPA client without a BFF, and the inability of resources to query the AS on every request. The design separates concerns so the AS handles only clients, tenants, grants, audiences, scopes, keys, sessions, and token issuance while the Main API owns profiles and roles. Tokens are managed securely inside a Service Worker using a custom FedCM grant, eliminating races across tabs and reducing XSS exposure. The approach minimizes blast radius, simplifies compliance, and keeps the AS replaceable without affecting product domain logic.

HabrOther

Why a 202-Character License Key Uses ECDSA P-256 Instead of Ed25519 or RSA

A developer building offline license verification for a .NET desktop application evaluated Ed25519, RSA, and ECDSA P-256 before selecting the last option. The decision was driven by the requirement for zero external dependencies, keys short enough for manual entry from email, and support for key rotation without breaking existing licenses. Although Ed25519 offers faster verification and a smaller public key, it is absent from System.Security.Cryptography in both .NET 8 and .NET 10, with API approval only targeted for version 11. RSA-2048 produces signatures too long for practical use, resulting in a 571-character Base32 string that users would find cumbersome. ECDSA P-256 with SHA-256 delivers a fixed 64-byte signature that becomes a manageable 202-character key when encoded in Base32, while remaining fully available in the runtime. The article also covers performance measurements, the risks of ECDSA nonce generation, and the deliberate choice of the IEEE P1363 signature format to guarantee fixed-length output.

HabrOther

Pilcrow Publishes Free Comprehensive Guide on Web Authentication

Author Pilcrow has released a detailed, ad-free handbook covering authentication and authorization practices for web applications. The resource draws on personal experience and includes practical examples in JavaScript and Go. It examines password-based methods, email verification, multi-factor authentication, passwordless flows, and passkeys while highlighting associated risks and usability trade-offs. The book also provides in-depth guidance on session management, token security, expiration policies, and email address handling as account identifiers. Recommendations emphasize choosing methods that match application security requirements and user expectations. Additional context is given on OWASP resources and community support channels.

HabrOther

redb 3.4.0 Adds Replay Checkpoints, Shared Runtime Layer and Declarative Secrets Handling for .NET Ecosystem

redb 3.4.0 delivers operational improvements for the .NET integration platform that includes typed storage over Postgres, MSSQL and SQLite, the redb.Route engine modeled after Apache Camel, the Tsak runtime with dashboard and clustering, and redb.Identity for OIDC and OAuth 2.1. The release focuses on post-deployment resilience with replay checkpoints that capture message state at named points inside routes, allowing safe re-execution of downstream steps without duplicating side effects. A shared runtime layer moves framework assemblies into a separate Libs/shared directory so that individual DLLs can be replaced without rebuilding or redeploying the entire Tsak or Identity packages. Secrets are now declared with a [Sensitive] attribute on endpoint options, ensuring URIs containing passwords or keys are sanitized before they reach logs, metrics or health checks. Additional controls include role-based access to management APIs, persistent audit trails and cryptographic signing of dynamically loaded modules. All Pro features remain free on the entire 3.x line with no licensing server required.