[LEAPSECS] Hetzner mail to customers: 1 megawatt more power due to leap second

[Michael Spacefalcon]

Gerard Ashton <ashtongj at comcast.net> wrote:


> Michael Spacefalcon wrote " a standardized, widely recognized and adopted

> scheme for converting leap seconds to rubber seconds is what we need"

> but also mentioned "a normal computer motherboard quartz crystal

> oscillator". But of course there are systems that are far more accurate than

> a normal

> computer motherboard by necessity, and those systems will not be able to use

> rubber seconds.


Ahh, there is a critical misconception: while it is true that systems
needing high-precision timing can't be reasonably asked to deal with
rubber seconds as long as every Alice and every Bob does his/her own
ad hoc rubberization (like Google said they did), I argue that rubber
seconds will become perfectly OK even for precision-timing systems
if the rubberization scheme were standardized.

Consider this example: suppose I were to create my own micronation,
call it the Principality of Falconia, and declared UTC-SLS to be
Falconia's official legal time.  Suppose you are an operator of a
high-precision timing system, but some legal/social/cultural
requirement compels you to display Falconian legal time in the user
interface, which has the rubber seconds of UTC-SLS.  Yet you want the
displayed time to be precise to the nanoseconds or even finer.  Can it
be done?  I say yes, because simple algorithmic rubberizations like
UTC-SLS (or my own UTR proposal, which is essentially the same thing,
but politically independent of UTC) derive their "rubber time" by an
*exact algorithmic formula* from atomic time.

So you could build your fancy high-precision timekeeping systems using
cesium fountains or whatever, using a TAI-style timescale as a
low-level internal implementation detail, but export a timescale like
UTC-SLS to the "civil/social time" layer, the software layer that
handles all human-visible times.  It would still be a high-precision
timing system, i.e., the rubber second times displayed by Alice's
system can still be made to agree with Bob's system down to
nanoseconds or whatever finer time precision you fancy.


> But at some point there will be an interface between

> the rubber second systems and the precise systems.


We already have this interface issue in the present world during
"normal", non-leap-second times.  I am using a system whose
timekeeping requirements are extremely coarse by the standards of this
list (being within a few seconds of GMT is all I need), and given such
low level of requirements, I've chosen an implementation that is
accordingly crude: each of my VAXen currently polls an ntpd-enabled
Linux box once an hour or so, asking for the time, then does a single
adjtime(2) call.  You, on the other hand, probably run a much more
precisely-timed system.  Yet we are able to exchange these emails
without any apparent problems.  That's an example of a low-precision-
timing system interfacing to a high-precision-timing system, isn't it?

It would be no different in a world standardized on UTR or UTC-SLS.
Each system would choose a high-precision implementation or a low-
precision one according to its needs, and the interoperability issues
would be no different from those that already exist currently during
normal, non-leap-second times.

Suppose that a rubberization scheme were officially defined as
something like this: "At such and such precise time, the length of the
civil second changes from exactly one SI second to exactly 1.001 SI
seconds. At such and such precise subsequent time, it changes back to
exactly one SI second."  A high-precision timing system could easily
implement these rules exactly, such that any two such systems anywhere
in the world would exactly agree on the rubberized civil time.  Yet a
low-precision timing system like a bedroom wall clock could be built
much simpler: not bother with the exact rubberization rules and simply
reset the clock to something "approximately right" at some hour of the
night like the current cheap RC clocks do.

The different choices made by low-precision systems differing from the
high-precision ones can't be construed as a new interface problem: it
is no different from the present situation in the absence of leap
seconds, where a low-precision system is expected almost by definition
to have an unpredictable time delta from the official precise time,
usually on the order of a few seconds, sometimes a minute or two.

SF