F-ckin Leap Seconds, how do they work?

Tyler Haske tyler.haske at gmail.com
Thu Jul 5 18:40:28 UTC 2012

On Thu, Jul 5, 2012 at 2:02 PM, Roy <r.engehausen at gmail.com> wrote:
> On 7/5/2012 10:42 AM, Steve Allen wrote:
>> On Thu 2012-07-05T10:26:22 -0700, Roy hath writ:
>>> Lets see.  There have been nine leap seconds in 20 years.  So at the
>>> start of the next century the difference will probably be less than a
>>> minute
>> There is no predicting how large the decadal variations in LOD will be,
>> but the difference should be somewhere between 1 minute and 3 minutes.
>> Please see these charts and tables for how unpredictable it is.
>> http://www.ucolick.org/~sla/leapsecs/dutc.html
>>> Remember OpenTime is only for people who want their system clocks to
>>> ignore leap seconds.  I don't include myself among the possible users of
>>> OpenTime.
>> Anyone who needs that can already do that using existing, deployed,
>> and tested code and hardware and the GPS system time scale.  Please
>> see this worked example.  Please do not invent yet another private
>> time scale.
>> http://www.ucolick.org/~sla/leapsecs/right+gps.html
>> ...
> So basically the concept of OpenTime is already implemented.  All that's
> needed is a list of Stratum-1 servers that anyone can use.

>From the website:
The scheme described in this web page uses a non-standard NTP server
and a non-standard set of "right" zoneinfo files. The hard part is
that the zoneinfo files must be hacked for GPS time and recompiled
whenever a leap second is announced. Hopefully that recompile happens
long before the leap second occurs. In this scheme the kernel does not
have to handle the leap second. All of the handling of the leap second
happens in the zoneinfo files. This is effectively the same as the
bi-annual handling of daylight/summer time transitions. There are no
real-time changes. Everything about the changes can be easily tested
at any time by any user.

Wouldn't an easier way to be separate out the timescales where one is
just 84600 seconds a day for the next 100 years, and another can keep
accurate time for those that need that kind of accuracy? The POSIX
standard can remain unchanged, and time can be monotonic.

When the cumulative difference like like 5 minutes, we can have a huge
pubic 5 year lead time thing to sync the timescales again. (Kind of
like DST, no mater how publicly and how often and how well you tell
people, folks will still show up to work late).

>From the website again:
A system whose time_t is set using an NTP server giving GPS time (thus
the kernel does not have to handle leap seconds) and which is
configured to use the usual zoneinfo files will produce formatted
date/time strings which are 15 seconds larger than official time. (The
value 15 will increment at each leap second.)
According to the developer forums this is the variation that Google
has chosen for Android devices.

This seems like a good kludge. But a second is an arbitrary measure.
We might as well add leap half seconds, or leap tenths of a second.
I'd prefer leap minutes, so we can have these kinds of threads about
1/60th of the time :)

Not that I don't find this entertaining.

More information about the NANOG mailing list