Date: Fri, 17 Jul 2026 20:04:59 -0400
From: Brooks Harris via tz<[email protected]>
Message-ID:<[email protected]>
[I have been very poor todat in correctly modifying mail to send a copy
to the list! This is the 2nd (out of 2) I messed up!]
| This is an interesting and reasonably well researched article.
Not really, the author was obviously fed a whole bunch of facts
(or used an AI to fetch them perhaps), but aside from:
| However, there is a badly misstated paragraph:
which was indeed a glaring error, there's lots more that is wrong
with it.
Consider this:
a situation fixed in Go 1.9 by adding a monotonic clock source,
but fixed specifically for the scenario where a timestamp repeats,
not for the scenario where a timestamp is skipped.
I mean, really - if it is now using a monotonic clock (which is the
sane thing to do when the time of day isn't what is interesting, but
measuring durations, etc) it no longer cares about leap seconds, or
for that matter, civil timekeeping, at all, just that seconds tick
past at a regular even rate, which they do using a monotonic clock,
whether there is a positive, negative, or even the fictional multiple
at once, leap second, or none of them.
A negative leap second produces a different class of failure.
That's true, in that it is one that most likely happens for reasons other
than leap seconds all the time anyway. The article suggests (with no
evidence whatever) that the problems are likely to be worse than those that
have been experienced with added leap seconds, but the reverse is far more
likely.
The examples given of what could happen are mostly nonsense, any distributed
database that can't handle transactions arriving out of order would have
failed long ago, variable networking delays are going to make that kind of
thing a daily occurrence. Further, if there is a negative leap second:
find a record timestamped 23:59:59 arriving after a record
timestamped 00:00:00,
is of course impossible, as there would be no 23:59:59 in that particular
hour (since it is being assumed that a negative leap second occurs then)
so nothing should ever be timestamped at that (never occurring) time.
Scheduled task queues that check "how long until my next deadline"
could find their deadlines appeared to have already passed.
They could indeed - as they can now, just because of scheduler delays,
meaning that the process doesn't get run exactly when it hoped it would
be - any half competent software deals with that already, it isn't hard.
"A negative leap second has never been added or tested,
so the problems it could create are without precedent,"
That might be true, I have no idea, it is very hard to know what has
never been done - we know an actual one hasn't happened, but how can
anyone ever claim to know that no-one has ever tested for the possibility ?
"has never been foreseen or tested"
The forseen part is complete balderdash, the possibility for negative
leap seconds has been around forever, though they may not have been
expected to occur given the rotational changes that have been occurring.
But the possibility of one coming sometime soonish has been considered
now for several years (at least) - there is nothing at all unforseen
about them, and again, no-one can possibly really claim to know what
has never been done (tested).
The comparison to Y2K has been raised by multiple researchers
- with the critical caveat that Y2K had decades of warning and
extensive testing, while a negative leap second has had neither.
The possibility of negative leap seconds has had just as much warning,
and most of the issue with Y2K was that it hadn't had much testing (and
the nature of the problem was totally different to leap seconds, that
they're both related to times/dates in some way, is really irrelevant).
That little advance testing of leap seconds happening occurred is poor,
but about what can be expected of most commercial enterprises.
Then:
Google has spread each leap second across a 24-hour window centered
on the leap event - running clocks slightly slower than usual during
the smear period - since 2008, [...]
During a smear window, a server using one provider's approach and
a server using another's may be measurably apart in time - sufficient
to corrupt timestamp ordering in distributed systems that span cloud
providers.
And as it says, this has apparently been happening since 2008, a period
in which there have been several leap second (2008, 2012, 2015, 2016)
so there should be demonstrated evidence of the problems this is supposed
to cause - but nothing was cited to support this, sounds like all supposition
to me.
This fragmentation means that even if a negative leap second were
handled perfectly by one provider's infrastructure, systems
communicating across provider boundaries during that window would
face the same ordering ambiguity that causes failures in simpler
scenarios.
And somehow that is supposed to be different for smearing for negative
leap seconds than it is for positive ones? Why? FUD.
A negative leap second, applied to systems that have been patched
for positive events but never tested for negative ones, represents
a materially larger and less-bounded risk than any of those precedents.
More FUD. No evidence, not even a hint of any rational explanation
why that would be.
A positive leap second results in a timestamp, which without leapseconds,
(and no smearing) could never happen 23:59:60, so the possibility that
when it does, errors might occur, is (or was perhaps) certainly there.
A negative leap second merely means that a timestamp that might have been
expected to be seen, is missed. Not an uncommon event at all.
Provided software that expects to actually count elapsed seconds is
using a monotonic clock, which it needs to be to survive positive leap
seconds correctly (without a whole bunch of special case code), negative
leap seconds should be much less of an issue than positive ones. Some
testing would certainly be a good idea, and I expect would happen in the
6 months (approx) notice that would be available were one ever to actually
happen (though knowing the way that many places feel about adding tests
which add to costs, perhaps not, but that's on them).
Go's standard library added a monotonic clock source in version 1.9
(August 2017), which prevents elapsed-time calculations from
returning negative numbers during a positive leap second. That fix
addresses one class of failure. It does not prevent the class of
failures caused by a timestamp being skipped rather than repeated.
Does the author have any idea at all what a monotonic clock is?
"The impact of a negative leap second has never been tested on a
large scale; it could have a devastating effect on the software
relying on timers or schedulers."
The "on a large scale" is new, and suggests that it has in fact been
tested, which would be contrary to the earlier statements which said
"never tested" without qualification, but that's certainly a plausible
statement, "it could" have devastating effects, and of course, it is
always best to predict the worst, if that happens, they predicted it.
If it doesn't, then that's fantastic, and no-one cares about the
incorrect predictions. Predict "all will be fine" and then if it
isn't, it is all on you - so no-one is ever going to do that. More FUD.
But none of that is nearly as frightening as what the article goes on
to predict as a possible future:
When it [allowing much greater UTC - UT1 offsets] goes into effect,
the last-minute-of-the-day adjustment mechanism would be retired,
and any remaining gap between UTC and UT1 would accumulate silently
until a leap-hour correction - likely manageable as a smear rather
than a discrete jump - becomes necessary generations from now.
First, the suggestion there is that everyone would go back to hiding their
heads in the sand, as nothing is going to change until "generations from
now" - by which time there will be so much more software around, all written
by people who blindly assumed there's nothing to worry about, until suddenly
there is. That's a horrific prospect to deliberately plan for. It is bad
enough when it just happens because people are lazy/ignorant, but to actually
expect things to happen like that is outrageous.
Further the prospect of smearing an hour is frightening to me. Just doing
it for a second, is bad enough, though survivable as the world has shown
in the past couple of decades, but an hour? 3600 seconds? Almost 10 seconds
a day, every day for a year. Really? What an absurd proposition.
On the other hand, a leap hour, positive or negative, every 50-100 years
is something that can be handled. We know that, as that's effectively
what happens when summer time turns on and off - much of the world is very
familiar with that, and we manage to cope. Certainly if everyone stops
doing summer time conversions, the practice of dealing with it will atrophy,
and it would likely cause some problems, but nothing likely to be nearly as
bad as altering the length of the second (for timekeeping, but not for
measuring durations) for a year or more. Software might need updating to
deal with it, but there would be nothing too hard to handle with that.
And last from the article:
The clock on your wall will continue ticking normally through
midnight on December 31, 2026, as Bulletin C 72 has now confirmed.
which, as this was clearly written for Americans, primarily, again
illustrates that the author has no idea how any of this works.
Leap seconds are inserted (or removed) at 23:59:59 on Dec 31, or
June 30, as that says isn't going to happen this coming December,
but that time isn't related to "The clock on your wall" unless your
wall clock happens to be displaying UTC (which might be true in the
UK in December, it wouldn't be in June, at least not as things stand now.)
On the other hand, if various countries are actually inserting the leap
second (as only inserts have ever happened so far) at midnight, wall clock
time (which I personally doubt), then we already have (and would have had for
years) times when the world's clocks would have been different by a second
for various periods on the days when leap seconds were inserted, and all
those synchronisation issues that the article suggests would be disasters
should have been happening every time.
And then while I'm here, unrelated to leap anythings:
| In any event I think it's not nearly as disruptive or dangerous as the
| Sunshine Protection Act.
There is nothing dangerous about that proposal, disruptive certainly,
any change is, and yet legislatures make disruptive changes (some of
which some people like, and others dislike, just like that one) all the
time - may of them with far worse effects that changing timezones can
ever have. Timezone alterations have been made in many places around
the world, many times now, and "dangerous" is about the least appropriate
adjective to apply to any of them. Stupid occasionally (as the places
that decided to jump the date line so they could be first into the new
millennium show), but dangerous?
I understand that you don't like the proposal, and that's fine - personally
I quite like summer time (when I am in AU in an area which really benefits
from it). Many people don't like it - and much of the US, and I think all
of Canada, is really at too high a latitude for it to work all that well.
Summer time variations work best in the middle latitudes, say between 30
and 40 degrees north or south. The further you move away from that range
the less effective it becomes. It also makes a difference where your
particular area is wrt the line of longitude that defines your natural
timezone.
But keep the dislike proportionate, there are far worse decisions being
made in the US than that one.
kre
