Michael Spacefalcon gave an overview of how a high precision system (which he incorrectly supposed I possessed or ran) could interface to a low precision system. But if a rubber time scale ever became law, high precision systems might have to interface with each other indirectly through the rubber time scale because of legal requirements. This would cause the interface systems to operate a little differently near leap seconds than they usually do, so there would be a potential for flaws to crop up. History suggests these interfaces will not be tested frequently enough.
Also note that this time it is medium-precision systems that failed; the coarse systems like Windows desktop systems that invoke their NTP client once a week did fine, and did fine when interfacing with medium-precision systems if the medium-precision systems were operating at all. Gerard Ashton -----Original Message----- From: leapsecs-boun...@leapsecond.com [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Michael Spacefalcon Sent: Thursday, July 05, 2012 5:28 PM To: leapsecs@leapsecond.com Subject: Re: [LEAPSECS] Hetzner mail to customers: 1 megawatt more power due to leap second Gerard Ashton <ashto...@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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
