Hi Scott,

The LSEM month suggestion retains the UTC policy of leaps being exactly +1 or -1 second, never larger, never smaller.

There's a world of hurt if anyone even dreamed of shifting UTC by a fraction of a second. In fact, one of the main reasons UTC was created in the 70's was to put an end to the dreaded fractional jumps in atomic timekeeping during that era. Fractional steps atomic frequency and fractional steps in atomic time were both tried during 60's. For example:

http://www.leapsecond.com/history/wwvb1966.htm

Eliminating frequency jumps completely (by defining the UTC second to be 9,192,631,770 Hz cesium), and
changing any steps to be full +1 or -1 second integers (and not fractions) was why UTC was created.

/tvb

----- Original Message -----
From: "Scott Stobbe" scott.j.stobbe@gmail.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Thursday, July 21, 2016 3:06 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Apropos Bob's comments, the problem of ambiguous timestamps during a
leap second, at least with current operating systems, is only made
worse by more frequent leap seconds.

Making critical systems run on a leap second free time scale like TAI,
for example, just shifts the problem to the interface between those
systems and the rest of the world. Admittedly, this interface may be
more tolerant of discrepancies.

Leap seconds have gotta go.

Cheers
Michael

On Fri, Jul 22, 2016 at 8:13 AM, Bob Stewart bob@evoria.net wrote:

Hi

A leap millisecond …. there’s an idea to explain to grandma. If you accept the idea that
we need a leap second ever year or three, it’s not going to be a millisecond. Something
messy would be required if you went below 100 ms. 100 ms would (barely) accommodate
a “once a year” leap second. If it was a 0.1 sec event, you would not get the nice “back and forth”
process for debugging and testing systems quite as often.

Bob

On Thu, Jul 21, 2016 at 5:27 PM, Tom Van Baak tvb@leapsecond.com wrote:

I think dithered leapsecond would be a massive improvement over what
we have now, I'd even pay for travel to send someone to advocate it at
whatever relevant standards meeting was needed.

But I still think it is inferior to no leapseconds at all (and
adjusting timezones after the several thousand years required to make
that needed).  The reason I hold this is three fold:

(1) The complexity to deal with leapseconds remains in LSEM. It won't
be as much of a constant source of failure but correct handling is a
real cost that goes into the engineering millions of
products/projects. Some of the current practical methods of handling
leap seconds (like shutting off/rebooting critical systems or
discarding data) would also be less reasonable with LSEM. They might
be less needed with LSEM but I cannot say that they would be
completely unneeded*.

(2) I'm not aware of any application that cares greatly about the
precise alignment with the mean solar day that doesn't need to go on
and apply location specific corrections.  Those applications could
easily apply the UTC to mean solar adjustment along with their
location specific adjustment.

(3) Obtaining the leap second sign requires a trusted data source.
When UTC has leap seconds a happily ticking atomic clock cannot keep
second level alignment with UTC without some trusted source of data.
Existing mechanisms for distributing leap second information have
communicated false information in several well known events in the
past, and these were accidents not malicious cases. LSEM would improve
this somewhat, since there would always be an update you just need to
learn the sign, so communications failures could be detected and
alarmed. But the need for this trusted input still creates a security
vulnerability window that could be avoided. Systems where their
security/integrity depend on time sync, could be pushed 24 seconds out
of sync in one year by an attacker that can control their leap
observations-- creating error greater than their free running
oscillators might have absent any sync at all.  This is especially
acute in that in a decade or two we might have 1PPB solid state
optical clock chips which are inexpensive and allow for "set once and
run forever without sync" operation for a great many applications --
getting potentially 0.5 ppm of error added on top from the lack of
leap seconds would basically limit the civil time performance of
unsynchronized clocks what you can get from a TCXO bought off mouser
for a couple bucks today.

So: It's my experience that the current handling of leap seconds is a
slow motion disaster. LSEM would be a big improvement-- reducing the
costs to the "intended costs" by eliminating many of the extra costs
created by inadequate testing. But it would not eliminate the base
cost of continuing to have our civil time perturbed by leap seconds to
begin with-- costs that are only increasing as atomic oscillators come
down in price and applications with tight synchronization requirements
become more common.

(*) once a month is not adequate testing to ensure freeness of fringe
race conditions. Meaning that at a minimum large scale life or large
value handling systems that might be impacted would still get the
reboot treatment in LSEM, but now with disruption every month.

On Thursday, July 21, 2016, Michael Wouters michaeljwouters@gmail.com
wrote:

No leap seconds seems preferable to more frequent leap  seconds.

--
Michael Rothwell
michael@rothwell.us
(828) 649-ROTH

Tom Van Baak wrote:

Although this approach sound good, it would cause major problems for
users of the German longwave transmitter DCF-77. The data format only
has a "leap second pending flag", which means a leap second is to be
inserted. AFAIK there is no spec to announce a negative leap second via
DCF-77.

Martin

Am 22.07.2016 um 10:44 schrieb Martin Burnicki:

I agree that LSEM seems like a good idea to get rid of the problem that leap seconds are happening not often enough to be in everyone's mind.

And I also agree that handling these monthly leap seconds would not adding complexity because you have to handle the occasional leap second anyway.

However, I believe that LSEM is not a good idea because of two things:
First, you would dramatically increase the efforts to distribute leap second announcements. At the moment a leap second announcement is announced roughly 6 months in advance, allowing to update devices in the field within a reasonable window of 4-5 months before the event. Doing it every month requires more frequent updates of lots of systems that currently have no connection to a leap second announcement information source like GPS or the Internet.

The second point is that the difference between solar time and UTC, which seems to matter at least to a considerable amount of people, is going to be higher compared to the current handling of leap seconds. If the IERS happens to determine that the Earth rotation speed was pretty constant last month and the time difference has increased only a few milliseconds since last month, you consciously have to increase it to one second minus the small actual difference. And then, in the next month, you have to basically jump back again.

Clearly getting rid of the leap seconds is the solution that requires the lowest effort both in terms of costs and technology. You do not have to touch a single device if you just keep the number of leap seconds constant from now on. With LSEM you have to touch probably 99% of all computer systems (their OS and possible applications) and at least 90% of all GPS receivers and clocks using other technologies.

And: the failure to get rid of this thing in the past should teach us how easy it will be to convince the ITU and the governments of the planet to change the current practice and go for LSEM.

Heiko

Hi

The practical problem with any change to leap seconds is transition from what we have
to the “new system”. Anything other than dropping them altogether involves a lot of
coordination. You pretty much have to pick a date and bring everything onto the new
standard then. For testing purposes your time sources should “advertise” the new
information ahead of that date. As a practical point, that means a new field in the data.
In the case of GPS and other space based systems, that’s not going to happen.

The alternative is to have a “magic date” and a pre-defined set of dither bits for the
next year or two after that. Yes that’s a mess on top of a mess. It does allow people to
roll out a patch that can be tested ahead of time. They can then transition to the full
blown approach. If you think about the amount of time needed to do this … two years
may not be enough …

This indirectly gets into the systems question of: How early do you announce the dither
bit for a given month? There are systems that do not get their leap second information
from broadcast or live network sources. You would have to put out the pattern early
enough to accommodate their “pipeline”. If that involves manually loading files … yikes.

Bob

Hi Tom,

Thanks for your insights on days past, and great website. I haven't
convinced myself that you can always guarantee | DUT1 | <= 1 if you force a
leap second at the end of each month. Certainly would aid in combating
sketchy code. I tried it on a very rudimentary model to visualize it.

On Thu, Jul 21, 2016 at 6:58 PM, Tom Van Baak tvb@leapsecond.com wrote:

This is a non starter. Even if there was agreement by the time lords, implementation would need to wait about 2x the MTBF of tantalum capacitors, say 50 years or so, so that the stuff that is running on our benches will have long been recycled.  I will bet that less than 10 percent of it has been verified to accept negative leaps.

I am a rubbery seconds supporter myself. It is about time we realized that humans are not machines and like the idea of 86400 second days from here to the end of time.
There is of course a need for precise SI time intervals and a time scale to go with, but that can be distributed alongside an 86400sec day UTC. The techno exists, we just need the will to say that we humans take precedence. UT1 rules.

I’ll jump down from my drum and share some data which I have not seen here before.

As most of you will already be aware, one of the results of the never-ending arguments about what to do with leap seconds, was that the IERS agreed to make available electronically  UT1-UTC deltas with much greater precision than the GPS stream does (0.1 sec resolution). AFIK we don’t have that yet, but at the beginning of June 2015, Judah Levine at NIST announced that NIST would be distributing high resolution UT1 in NTP frames .
See < http://www.nist.gov/pml/div688/grp40/ut1_ntp_description.cfm>.

As you can see from the document, the service was available to registered users with static IP addresses. My ISP only hands these out for $$$s so I registered with some of the cheaper VPN providers ones to test out the service over VPN links. Unfortunately there were such severe latency and jitter issues with all of those that I tried, that I abandoned my tests in August 2015. I also think I unfortunately pissed off Judah with my repeated requests for IP address registration as he stopped responding to mails. Sorry for that Judah if you are looking in.

Anyway I forgot all about it until the other day when I was looking at the peerstat data of the server I was using for the tests and discovered that the UT1 server was alive and responding over my unregistered IP with half the latency and usec level jitter. Luckily I had left the address in place in my ntp.conf with noselect  option.
Here is the ntpq -pn data.
mike@cubieez2:~/NIST_UT1_server_data$ ntpq -pn
remote          refid      st t when poll reach  delay  offset  jitter

---============
+192.168.1.23    .GPS.            1 u  61  64  377    0.173  -0.014  0.024
128.138.140.50  .NIST.          1 u  41  64  377  130.670  -225.01  0.102

You will also note from the NIST document and the NIST time server address links, that the UT1 NTP service will not respond to unregistered requests.
NIST may or may not have opened the box deliberately. I don’t know, but if you wish to use the service please at least contact Judah before doing so. It would be a shame to have it going deaf.

Anyway, here are the results from the data I collected.
I have graphed the UT1 server offsets reported by the NTP peerstats data over the last 20 days and also the observed UT1-UTC deltas from IERS Bulletin A and the predicted UT1-UTC deltas for the same period from Bulletin A.

As you can see, there is a systematic offset from the observed values reported in Bulletin A but the served value appears to track the predictions rather than the observed values. The resolution is much better than the 0.1s available via GPS but as the UT1 time is constant over the 24h day, it is not good enough to make a rubbery seconds clock. We need some interpolation.

The 13/14th of July something strange was going on. I was not monitoring this system at the time and have no idea what it was.

"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw