[time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Mark Sims]

The GPS satellites are now reporting the pending leapsecond...

The Z3801A has it messed up... it says the leap will occur on 30 Sep 2016 (73 days). The Z3801A has two different messages that report the leap day... both are wrong.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Hi Mark,

Three comments:

1)
I recall this is a known problem in the Z3801A status reporting, and possibly other GPS receivers of that era as well. It stems indirectly from a change years ago in how far in advance IERS and DoD were able to update the leap second info into the GPS constellation. Nowadays it's common to get 6 months notice; it wasn't always that much.

We typically reserve the word leap second "pending" for the month in which the leap second will actually occur. So just because we now know a leap second will occur in December we don't say, here in July, that a leap second is pending. Instead we say a leap second has been scheduled, or has been announced, or something like that.

There's more info on all of this back in the time-nuts and LEAPSECS archives if you want to dig deeper.

2)
Note this is not a problem for LF time services like WWVB which reserve two bits; one that tells you if a leap second is pending (this month) and one that tells you if it's an insert (positive) or delete (negative) leap second. For WWVB it's either this month or it's not at all.

It's a minor problem for NTP because it AFAIK it can only tell you one day in advance if a leap second is going to happen at midnight.

It's a mess for NMEA; there are no standard messages that give leap second announcements. The time just jumps or stutters, whether you or your boating equipment expects it or not.

It's not a problem for GPS because internally a leap second is not indicated by flag bits at all. Instead they use two fields for the pre- and the post- UTC-GPS offset, as well as the GPS week/day number when the change takes/took effect. So there's the potential for years of advance notice of a leap second.

So GPS is robust, WWVB is fine, avoid NMEA, and NTP is kind of fragile with respect to leap second announcements. I assume Galileo does it right. GLONASS, on the other hand, is known to have problems every time there's a leap second.

Just to be clear, this Z3801 anomaly is not a GPS problem. IIRC, it's not even an Oncore VP GPS board problem either; instead the hp CPU firmware is overly enthusiastic about how to transform a GPS leap second *announcement* into a Z3801A leap second *pending*. But it all works out fine in the end; this has happened on other recent leap second announcements, so not to worry.

3)
Some things to know, as a writer of software that involves users, GPS receivers, and leap seconds...

If you're writing embedded software try to never hardcode any leap second tables.

In general there's a common belief that a leap second can only occur at the end of June or December. This is false. Don't ever hardcode this assumption.

There's also a less common belief that a leap second may occur at the end of March, June, September, or December. This is also false. Don't hardcode this either.

IERS is free to schedule a leap second at the end of any month. And it may be an insert or a delete. Assume nothing more or less in your code. Code and test and document for positive and negative leap seconds equally.

I say this because with the gradual warming / melting of the planet since the last major ice age we may soon enter a decade where the earth returns to a "normal" 86400.000 seconds per day or even a bit less. In that case we'll switch from positive leap seconds for a while, to no leap seconds for a while, to negative leap seconds for a while. We got very close to this during the years 2000 - 2007, when we entered the "no leap seconds for a while" stage.

I don't normally cross-post, but I'll cc the leap second list for comments or corrections.

/tvb

----- Original Message -----
From: "Mark Sims" <***@hotmail.com>
To: <time-***@febo.com>
Sent: Tuesday, July 19, 2016 4:39 PM
Subject: [time-nuts] Leap second to be introduced at midnight UTCDecember 31 this year

Post by Mark Sims
The GPS satellites are now reporting the pending leapsecond...
The Z3801A has it messed up... it says the leap will occur on 30 Sep 2016 (73 days). The Z3801A has two different messages that report the leap day... both are wrong.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Gary E. Miller]

Yo Tom!

Here we go again. Leap seconds always cause stress...

On Tue, 19 Jul 2016 22:08:48 -0700

Post by Tom Van Baak
In general there's a common belief that a leap second can only occur
at the end of June or December. This is false. Don't ever hardcode
this assumption.

NTP Classic thinks otherwise:
http://bugs.ntp.org/show_bug.cgi?id=1090

gpsd follows the lead of NTP folks.

Post by Tom Van Baak
IERS is free to schedule a leap second at the end of any month. And
it may be an insert or a delete. Assume nothing more or less in your
code. Code and test and document for positive and negative leap
seconds equally.

Got a reference for that? I know many people that will insist otherwise.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
***@rellim.com Tel:[phone]

[Gary E. Miller]

Yo Tom!

Post by Gary E. Miller

Post by Tom Van Baak
IERS is free to schedule a leap second at the end of any month. And
it may be an insert or a delete. Assume nothing more or less in your
code. Code and test and document for positive and negative leap
seconds equally.

Got a reference for that? I know many people that will insist
otherwise.

Never mind, I think I found a reference that is commonly quoted:

CCIR Recommendation 460-4 (1986).

http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en

2. Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.

But it is marked Superceded. I'm guessing that is replaced by 460-6?

http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en

It says the same thing in section 2.1

Nothing says it has to be those 4 months...

I have some code comments in gpsd to fix...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
***@rellim.com Tel:[phone]

[Magnus Danielson]

Gary,

Post by Gary E. Miller
Yo Tom!

Post by Gary E. Miller

Post by Tom Van Baak
IERS is free to schedule a leap second at the end of any month. And
it may be an insert or a delete. Assume nothing more or less in your
code. Code and test and document for positive and negative leap
seconds equally.

Got a reference for that? I know many people that will insist otherwise.

CCIR Recommendation 460-4 (1986).
http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en
2. Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.
But it is marked Superceded. I'm guessing that is replaced by 460-6?
http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en
It says the same thing in section 2.1
Nothing says it has to be those 4 months...

No, but the wording do say that those four month is preferred. For those
that is curious:
http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf

8<---
2 Leap-seconds

2.1 A positive or negative leap-second should be the last second of a
UTC month, but first preference should be given to the end of December
and June, and second preference to the end of March and September.

2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of
the first day of the following month. In the case of a negative
leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s
of the first day of the following month (see Annex 3).

2.3 The IERS should decide upon and announce the introduction of a
leap-second, such an announcement to be made at least eight weeks in
advance.
--->8

Thus, any month can be scheduled, but there is a preference to end of
half-year and then end of quarter. The main preference is used in
practice, which is in good accordance with the rules, the Z3801A
designers over-eagerly included also the remaining two end-of-quarter.

Post by Gary E. Miller
I have some code comments in gpsd to fix...

Yes, but it can take a long time before it would bite you.
Beware of GPS-receivers such as Z3801A which now give the time of leap
second 3 month to early, and beware that eventually end of March and end
of September might become legal points even for a Z3801A.

Now, what annoys me is that the IERS message says that the leap second
is scheduled for January:

8<---

Paris, 6 July 2016

Bulletin C 52

To authorities responsible for the measurement and distribution of
time


UTC TIME STEP
on the 1st of January 2017


A positive leap second will be introduced at the end of December 2016.
The sequence of dates of the UTC second markers will be:

2016 December 31, 23h 59m 59s
2016 December 31, 23h 59m 60s
2017 January 1, 0h 0m 0s
--->8

It is unfortunate that it says UTC TIME STEP on the 1st of January 2017,
as it is scheduled for 31 December 2016.

This is a new habbit of IERS, and it is unfortunate and not helpful.
Older Bullentin C used the more correct reference to end of June or end
of December.

Ah well.

Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Martin Burnicki]

Magnus,

Post by Magnus Danielson
Now, what annoys me is that the IERS message says that the leap second
8<---
Paris, 6 July 2016
Bulletin C 52
To authorities responsible for the measurement and distribution of time
UTC TIME STEP
on the 1st of January 2017
A positive leap second will be introduced at the end of December 2016.
2016 December 31, 23h 59m 59s
2016 December 31, 23h 59m 60s
2017 January 1, 0h 0m 0s
--->8
It is unfortunate that it says UTC TIME STEP on the 1st of January 2017,
as it is scheduled for 31 December 2016.

Hm, the leap second is inserted at the end of December 31 (which is also
said by the message text), but as a consequence the beginning of January
1 is delayed by 1 second, so IMO this statement might be correct, even
though it's not formulated very clearly.

Post by Magnus Danielson
This is a new habbit of IERS, and it is unfortunate and not helpful.
Older Bullentin C used the more correct reference to end of June or end
of December.

Hm, the oldest bulletin C I found on the IERS web site already has the
same statement:
https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.10

I find it amusing that until ~2011, if no leap second was scheduled, the
message text said:

"NO *positive* leap second will be introduced ..."

If you're nitpicking you could have expected that eventually a
*negative* leap second was to be scheduled. ;-)

Martin

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Hi Gary,

2.1 A positive or negative leap-second should be the last second of a UTC month,
but first preference should be given to the end of December and June,
and second preference to the end of March and September.

Sounds correct. The point is to never to hardcode a "preference". You code against a spec. And the spec is simple:

"A positive or negative leap-second should be the last second of a UTC month"

It would appear that assuming the preference was actually a rule is what causes the Z3801A f/w to mis-report the next leap second as September instead of December. Back in the late 90's, when the 58503/Z3801 code was written, this made sense. Leap second annoucenements were not made half a year in advance back then.

/tvb

----- Original Message -----
From: "Gary E. Miller" <***@rellim.com>
To: "Tom Van Baak" <***@LeapSecond.com>
Cc: "Discussion of precise time and frequency measurement" <time-***@febo.com>
Sent: Tuesday, July 19, 2016 10:36 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Yo Tom!

Post by Tom Van Baak
IERS is free to schedule a leap second at the end of any month. And
it may be an insert or a delete. Assume nothing more or less in your
code. Code and test and document for positive and negative leap
seconds equally.

Got a reference for that? I know many people that will insist
otherwise.

Never mind, I think I found a reference that is commonly quoted:

CCIR Recommendation 460-4 (1986).

http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en

2. Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.

But it is marked Superceded. I'm guessing that is replaced by 460-6?

http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en

It says the same thing in section 2.1

Nothing says it has to be those 4 months...

I have some code comments in gpsd to fix...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
***@rellim.com Tel:[phone]

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Nick Sayer via time-nuts]

Post by Tom Van Baak
Hi Gary,

2.1 A positive or negative leap-second should be the last second of a UTC month,
but first preference should be given to the end of December and June,
and second preference to the end of March and September.

"A positive or negative leap-second should be the last second of a UTC month"

Even that’s weasel-worded. If they mean it, they should say it *will* or it *must* be the last second of a UTC month.

Words have meanings. :D

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Gary E. Miller]

Yo time-***@febo.com!

On Tue, 19 Jul 2016 23:18:18 -0700

Post by Tom Van Baak
In general there's a common belief that a leap second can only
occur at the end of June or December. This is false. Don't ever
hardcode this assumption.

http://bugs.ntp.org/show_bug.cgi?id=3D1090

If you read the fine print in that bug, you will see that it's a work
around for a bug in the HP firmware that is the core of this
discussion.

Yes, I know the problem being solved. Like today, the leap second being
broadcast sooner than ntpd expects, so it picks the wrong month.

I don't think there is anything in the core of ntpd that restricts
leap seconds to Jun/Dec. If there was, it would have filtered out
the above problem.

How about this:

ntpd/refclock_hpgps.c, line 544:

/* See http://bugs.ntp.org/1090
* Ignore leap announcements unless June or December.
* Better would be to use :GPSTime? to find the month,
* but that seems too likely to introduce other bugs.
*/
case '+':
if ((month==6) || (month==12))

Things get interesting if you are shipping code today that will last
for 10 or 20 years. My HP Z3801A has software dates from 1995 so 20
years isn't unreasonable. Of course, they were retired from
commercial use a long time ago, so maybe it's OK if the firmware has
bugs.

20 years? My house is 40 years old. In an IoT world people would like
to not throw away capital equipment every decade.

But i'm prolly spitting into the wind...

I don't know any software projects that handle this sort of thing
cleanly. (My exposure is limited.)

gpsd filters out all but June and December. So sort of cleanly, but
clearly work needed. I notice ntpd also filters out leap warnings for
the first short bit of the month. That might be worth doing too. I'm
sure something else will crop up before 2017.

If a giant asteroid hits earth, and we need a negative leap second in
March, there will be a lot of urgent patching to do.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
***@rellim.com Tel:[phone]

[Martin Burnicki]

Post by Gary E. Miller
On Tue, 19 Jul 2016 23:18:18 -0700

Post by Tom Van Baak
In general there's a common belief that a leap second can only
occur at the end of June or December. This is false. Don't ever
hardcode this assumption.

http://bugs.ntp.org/show_bug.cgi?id=3D1090

If you read the fine print in that bug, you will see that it's a work
around for a bug in the HP firmware that is the core of this
discussion.

If it's known that certain devices out there have a certain bug then
it's fine IMO to try to fix this in the device-specific part of the
code, i.e. in ntpd's particular refclock driver. As Hal has already
mentioned, I wouldn't consider the refclock driver as belonging to the
core functionality, just because it is part of the code tree.

Post by Gary E. Miller
Yes, I know the problem being solved. Like today, the leap second being
broadcast sooner than ntpd expects, so it picks the wrong month.

If the NTP specs say a leap second pending flag must not be set earlier
than month or 1 day before the leap second occurs then the upstream
software should account for this, regardless whether it's an upstream
NTP server, or a refclock driver.

From ntpd's point of view:

- If it receives a leap second announcement, in which case should the
announcement be accepted; in which cases (buggy upstream sources) rejected?

- When should ntpd start to pass a leap second pending flag on to its
clients?

- When should ntpd start to pass a leap second pending flag down to the
OS kernel, so that the kernel can handle the leap second?

If the leap second warning is passed too early then there's a good
chance for confusion. If ntpd already has a current leap second file
then it already knows about the upcoming leap second now, but it still
doesn't pass a leap second pending flag to its clients, or to the OS kernel.

Beside this there's still another point:

- What should ntpd do if there are different upstream sources which
disagree about an upcoming leap second?

In current ntpd versions:

- A leap second file has precedence unless it is outdated.

- If no valid leap second file is available then a leap second warning
from a refclock is accepted.

- If no valid leap second file is available then a leap second warning
from upstream NTP server is only accepted if a majority of servers
provide it.

Post by Gary E. Miller

I don't think there is anything in the core of ntpd that restricts
leap seconds to Jun/Dec. If there was, it would have filtered out
the above problem.

There has been such a check before ntpd 4.2.6, but the code has been
removed in current versions.

Post by Gary E. Miller
/* See http://bugs.ntp.org/1090
* Ignore leap announcements unless June or December.
* Better would be to use :GPSTime? to find the month,
* but that seems too likely to introduce other bugs.
*/
if ((month==6) || (month==12))

Things get interesting if you are shipping code today that will last
for 10 or 20 years. My HP Z3801A has software dates from 1995 so 20
years isn't unreasonable. Of course, they were retired from
commercial use a long time ago, so maybe it's OK if the firmware has
bugs.

20 years? My house is 40 years old. In an IoT world people would like
to not throw away capital equipment every decade.
But i'm prolly spitting into the wind...

I don't know any software projects that handle this sort of thing
cleanly. (My exposure is limited.)

gpsd filters out all but June and December. So sort of cleanly, but
clearly work needed. I notice ntpd also filters out leap warnings for
the first short bit of the month. That might be worth doing too.

On systems which support this (Linux, *BSD, etc.) ntpd just passes a
leap second pending flag to the kernel, and the kernel handles the leap
second. However, ntpd has to keep track of its internal leap second flag
which it sends out to the clients.

So only if it polls the kernel status *after* the leap second has
occurred and sees that the kernel's leap second flag has been cleared,
ntpd can clear its internal leap second flag which it sends to the clients.

So there's a chance that ntpd sends a leap second flag to client during
a short interval after the leap second until it has polled the kernel
status again and found that the leap second has passed by.

So if clients accept a leap second flag in advance then it's important
that there's some interval at the beginning of a month where they don't.

Post by Gary E. Miller
If a giant asteroid hits earth, and we need a negative leap second in
March, there will be a lot of urgent patching to do.

Yes. Specifically, the German long wave transmitter doesn't have the
possibility to announce a *negative* leap second.

Martin

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

Post by Gary E. Miller
Yes, I know the problem being solved. Like today, the leap second being
broadcast sooner than ntpd expects, so it picks the wrong month.

Do you know of any ntp servers that have picked the wrong month?

Post by Gary E. Miller

I don't think there is anything in the core of ntpd that restricts
leap seconds to Jun/Dec. If there was, it would have filtered out
the above problem.

I wasn't considering refclocks to be "core" in that context. Got a better
word?

Have you found any similar code that isn't in one of the refclocks?

Post by Gary E. Miller
20 years? My house is 40 years old. In an IoT world people would like to
not throw away capital equipment every decade.

Your house gets a new roof occasionally. The IoT world hasn't figured out
how to handle firmware updates and/or people haven't adapted to throwing out
gear that looks OK physically but has bugs, especially if the bugs don't
break the main function of the device.

Post by Gary E. Miller
gpsd filters out all but June and December. So sort of cleanly, but clearly
work needed. ...

The sort of "cleanly" I had in mind would be at the project management level.
Handwave. Each project should keep track of the assumptions in their code
that may not be correct many years in the future. That list should be
reviewed occasionally, say every year or few years.

It also has to be documented in a way that downstream users know what they
are getting involved with. This is a good example. Tom is arguing for
do-it-right according to the specs. I'm arguing for defensive programming
since we have already seen bugs in other gear. If you were packaging ntpd
into a box which would you want? Will your box last long enough to see a
leap second in Mar or Sep? Is your box going to connect to old/buggy gear?
Does your startup have enough funding to consider issues like this, or people
smart enough to understand the tangle?

[Martin Burnicki]

Post by Hal Murray

Post by Gary E. Miller

I don't think there is anything in the core of ntpd that restricts
leap seconds to Jun/Dec. If there was, it would have filtered out
the above problem.

I wasn't considering refclocks to be "core" in that context. Got a better
word?
Have you found any similar code that isn't in one of the refclocks?

ntpd versions before 4.2.6 also had a plausibilty check, which even had
a bug when checking for end of June. See:
http://bugs.ntp.org/show_bug.cgi?id=525#c0

Post by Hal Murray

Post by Gary E. Miller
20 years? My house is 40 years old. In an IoT world people would like to
not throw away capital equipment every decade.

Your house gets a new roof occasionally. The IoT world hasn't figured out
how to handle firmware updates and/or people haven't adapted to throwing out
gear that looks OK physically but has bugs, especially if the bugs don't
break the main function of the device.

Firmware updates? Why would anyone need this? ;-))

Post by Hal Murray

Post by Gary E. Miller
gpsd filters out all but June and December. So sort of cleanly, but clearly
work needed. ...

The sort of "cleanly" I had in mind would be at the project management level.
Handwave. Each project should keep track of the assumptions in their code
that may not be correct many years in the future. That list should be
reviewed occasionally, say every year or few years.

Agreed.

Post by Hal Murray
It also has to be documented in a way that downstream users know what they
are getting involved with. This is a good example. Tom is arguing for
do-it-right according to the specs. I'm arguing for defensive programming
since we have already seen bugs in other gear.

I'd say the best solution would be a combination of both.

Post by Hal Murray
If you were packaging ntpd
into a box which would you want? Will your box last long enough to see a
leap second in Mar or Sep? Is your box going to connect to old/buggy gear?
Does your startup have enough funding to consider issues like this, or people
smart enough to understand the tangle?

+1

Martin

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[David Malone]

Post by Hal Murray

Post by Gary E. Miller
Yes, I know the problem being solved. Like today, the leap second being
broadcast sooner than ntpd expects, so it picks the wrong month.

Do you know of any ntp servers that have picked the wrong month?

When I was writing up my leap second measurements, I went looking
for reports of leap seconds in unusual months (i.e. not in
June/Decembet) and managed to find the following:

http://lists.ntp.org/pipermail/questions/2007-October/015655.html
http://lists.ntp.org/pipermail/questions/2012-August/033611.html
http://lists.ntp.org/pipermail/questions/2013-July/035664.html

For the first, I think Windows was involved? For the second, I'm
not sure how many people accidently leaped. For the last, there was
definitely one leap.

David.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[David Malone]

Hi Hal,

I guess you know this but...

Post by Hal Murray
I wasn't considering refclocks to be "core" in that context. Got a better
word?
Have you found any similar code that isn't in one of the refclocks?

ntp_loopfilter.c used to have code that restricted the months for
leap seconds. The new core ntpd code doesn't do this check, though
if you have an up-to-date leapseconds file, it will veto bad
suggestions.

David.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Jay Grizzard]

Post by Mark Sims
The GPS satellites are now reporting the pending leapsecond...
The Z3801A has it messed up... it says the leap will occur on 30 Sep
2016 (73 days). The Z3801A has two different messages that report the
leap day... both are wrong.

I think some (modern!) Trimble gear may also has a problem. I have an ICM
SMT 360 board that's (slowly) flipping back and forth between showing a UTC
offset of 17 seconds and an offset of 18 seconds. This is their currently
shipping timekeeping chip, so it's surprising, but I don't know how else
to explain the behavior outside of a firmware bug.

(I've sent an email to Trimble support, but haven't heard anything back yet.)

-j
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Martin Burnicki]

Post by Jay Grizzard

Post by Mark Sims
The GPS satellites are now reporting the pending leapsecond...
The Z3801A has it messed up... it says the leap will occur on 30 Sep
2016 (73 days). The Z3801A has two different messages that report the
leap day... both are wrong.

I think some (modern!) Trimble gear may also has a problem. I have an ICM
SMT 360 board that's (slowly) flipping back and forth between showing a UTC
offset of 17 seconds and an offset of 18 seconds. This is their currently
shipping timekeeping chip, so it's surprising, but I don't know how else
to explain the behavior outside of a firmware bug.

The UTC/leapsecond data sent by the satellites contains the UTC offset
before and after the leap second event time. This has been 17/17 until
recently, and is 17/18 now.

The GPS satellites didn't start all at the same time to send the new
data set, so there was a period of time where some sats sent 17/17 while
some others already sent 17/18.

So when the GPS receiver always just *showed* information on the current
UTC data set then this is OK. However, the *time* it has *output* should
not have jumped back and forth by 1 second.

Martin

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Gary E. Miller]

Yo Martin!

On Wed, 20 Jul 2016 21:37:02 +0200

Post by Martin Burnicki
So when the GPS receiver always just *showed* information on the
current UTC data set then this is OK. However, the *time* it has
*output* should not have jumped back and forth by 1 second.

I have a report of a Venus8, with BeiDou, that jumped NMEA time by one
second on the 19th.

The NMEA offset data is fun:

Loading Image...

But some other, different, models of Venus8 did not.

I'm trying to get more information.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
***@rellim.com Tel:[phone]

[Mike Cook]

Post by Gary E. Miller
Yo Martin!
On Wed, 20 Jul 2016 21:37:02 +0200

Post by Martin Burnicki
So when the GPS receiver always just *showed* information on the
current UTC data set then this is OK. However, the *time* it has
*output* should not have jumped back and forth by 1 second.

I have a report of a Venus8, with BeiDou, that jumped NMEA time by one
second on the 19th.
https://dan.drown.org/bbb/latest/remote-statistics.NMEA.png

possibly related the the issue reported back in january 2015.

"Back in January it was reported here that the Venus 8 timing modules from Skytraq as used in the LTE-Lite, had a firmware bug that was causing the leap second to be applied as soon as the warning was seen in the GPS stream. I had bought one from Navspark and once I reported the issue they shipped me a replacement receiver as soon as the F/W update was available. I would have preferred the new F/W, but I got a free receiver as they did not want me to return the bugged one. "

Post by Gary E. Miller
But some other, different, models of Venus8 did not.
I'm trying to get more information.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Jay Grizzard]

Post by Martin Burnicki
The UTC/leapsecond data sent by the satellites contains the UTC offset
before and after the leap second event time. This has been 17/17 until
recently, and is 17/18 now.
The GPS satellites didn't start all at the same time to send the new
data set, so there was a period of time where some sats sent 17/17 while
some others already sent 17/18.
So when the GPS receiver always just *showed* information on the current
UTC data set then this is OK. However, the *time* it has *output* should
not have jumped back and forth by 1 second.

I don't actually know what the time it's outputting is (this particular
chip I'm grabbing stats from, but not time), but I'm pretty certain that
nothing should be returning '18' yet. In specific, from the docs for the
'UTC Offset' field in the Trimble docs for the TSIP primary timing packet
(0x8F-AB):

This field represents the *current* integer leap second offset between
GPS and UTC

(emphasis mine)

However, even if it was outputting the correct thing in the timing packets,
that only applies if the GPS is set to report UTC time rather than GPS time
(which is selectable on Trimble chips). You should be able to get GPS
time from the output and add the UTC offset to get UTC time, but that won't
work with the data this chip is currently outputting.

Even if reporting 18 is correct, though, Trimble still has a problem,
because my Thunderbolt is still reporting 17, and I'm pretty sure they're
not both right (same company, same protocol, different values). Either that,
or Trimble provides a "UTC Offset" field with every timing packet that they
don't actually intend for anyone to use for anything, but that would just
be weird.

-j
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Time to mention this again...

If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.

Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not so much by rare steps but by dithering. There would be no change to UTC or timing infrastructure because the definition of UTC already allows for positive or negative leap seconds in any given month.

Every UTC-aware device would 1) know how to reliably insert or delete a leap second, because bugs would be found by developers within a month or two, not by end-users years or decades in the future, and 2) every UTC-aware device would have an often tested direct or indirect path to IERS to know what the sign of the leap second will be for the current month.

The leap second would then become a normal part of UTC, a regular monthly event, instead of a rare, newsworthy exception. None of the weird bugs we continue to see year after year in leap second handling by NTP and OS's and GPS receiver firmware would occur.

Historical leap second tables would consist of little more than 12 bits per year.

Moreover, in the next decade or two or three, if we slide into an era where average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, there will be zero impact if LSEM is already in place.

/tvb

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Rob Seaman]

Hi Tom,

This message is an excellent example of why we invited you to speak at the Science of Time symposium ;-)

It was a shame you couldn’t make it, since you would have made an excellent meeting even stronger. But future meetings in the series seem very likely and let me register an invitation now...

Rob
—

Post by Tom Van Baak
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not so much by rare steps but by dithering. There would be no change to UTC or timing infrastructure because the definition of UTC already allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a leap second, because bugs would be found by developers within a month or two, not by end-users years or decades in the future, and 2) every UTC-aware device would have an often tested direct or indirect path to IERS to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly event, instead of a rare, newsworthy exception. None of the weird bugs we continue to see year after year in leap second handling by NTP and OS's and GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era where average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
LEAPSECS mailing list
https://pairlist6.pair.net/mailman/listinfo/leapsecs

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Holmes]

Hi Tom...

Does your proposal allow for a Zero leap second, or does it require either plus or minus 1 to work? Seems like you could stay closer to the true value if you also have a zero option. Might also cause less consternation for some services, like the finance and scientific worlds, that seem to have critical issues when an LS appears.

I like your point that by having it occur monthly it forces systems to address issues promptly, and maybe that's the argument for the non-zero option.

Tom Holmes, N8ZM


-----Original Message-----
From: time-nuts [mailto:time-nuts-***@febo.com] On Behalf Of Tom Van Baak
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <time-***@febo.com>
Cc: Leap Second Discussion List <***@leapsecond.com>
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Time to mention this again...

If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.

Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not so much by rare steps but by dithering. There would be no change to UTC or timing infrastructure because the definition of UTC already allows for positive or negative leap seconds in any given month.

Every UTC-aware device would 1) know how to reliably insert or delete a leap second, because bugs would be found by developers within a month or two, not by end-users years or decades in the future, and 2) every UTC-aware device would have an often tested direct or indirect path to IERS to know what the sign of the leap second will be for the current month.

The leap second would then become a normal part of UTC, a regular monthly event, instead of a rare, newsworthy exception. None of the weird bugs we continue to see year after year in leap second handling by NTP and OS's and GPS receiver firmware would occur.

Historical leap second tables would consist of little more than 12 bits per year.

Moreover, in the next decade or two or three, if we slide into an era where average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, there will be zero impact if LSEM is already in place.

/tvb

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

Hi

If you have a “zero option” then nothing ever gets tested. It always sits at zero and gets ignored. If you
dither back and forth +/- 1 second, it’s tested every month. The faulty system that does not follow the
signal gets spotted and fixed.

Bob

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require either plus or minus 1 to work? Seems like you could stay closer to the true value if you also have a zero option. Might also cause less consternation for some services, like the finance and scientific worlds, that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to address issues promptly, and maybe that's the argument for the non-zero option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not so much by rare steps but by dithering. There would be no change to UTC or timing infrastructure because the definition of UTC already allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a leap second, because bugs would be found by developers within a month or two, not by end-users years or decades in the future, and 2) every UTC-aware device would have an often tested direct or indirect path to IERS to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly event, instead of a rare, newsworthy exception. None of the weird bugs we continue to see year after year in leap second handling by NTP and OS's and GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era where average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Brooke Clarke]

Hi Tom:

I like this idea. I addresses the lesson from Y2K that something done often works much better than something done only
occasionally.
That's way you see the firetruck at the local store, because it's used all the time and so is more likely to work when
needed.
--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require either plus or minus 1 to work? Seems like you could stay closer to the true value if you also have a zero option. Might also cause less consternation for some services, like the finance and scientific worlds, that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to address issues promptly, and maybe that's the argument for the non-zero option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not so much by rare steps but by dithering. There would be no change to UTC or timing infrastructure because the definition of UTC already allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a leap second, because bugs would be found by developers within a month or two, not by end-users years or decades in the future, and 2) every UTC-aware device would have an often tested direct or indirect path to IERS to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly event, instead of a rare, newsworthy exception. None of the weird bugs we continue to see year after year in leap second handling by NTP and OS's and GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era where average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Jim Palfreyman]

The idea is the same as my local telco and their main exchanges.

Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in anger.

This leap second solution is the best I've heard so far.

Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it would
force the software problems to be fixed.


Jim Palfreyman

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Stewart]

But would it really solve your problems, Jim?  The problem is essentially that periodically, there are two different clock times that represent the same moment in time.  For telescopes, stock markets, spread spectrum, time-based encryption, etc that's a big problem.  Would it not be better to separate out those entities that are more dependent on precision sequence than on clock time and accept that they are just going to be different?  Yeah, the talking heads on CNBC and Bloomberg would gravely announce that today's stock market was opening a second later, but so what?  At least there wouldn't be any more questions about exactly when transaction X occurred.

Bob
 -----------------------------------------------------------------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

From: Jim Palfreyman <***@gmail.com>
To: Discussion of precise time and frequency measurement <time-***@febo.com>
Sent: Thursday, July 21, 2016 4:38 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

The idea is the same as my local telco and their main exchanges.

Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in anger.

This leap second solution is the best I've heard so far.

Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it would
force the software problems to be fixed.


Jim Palfreyman

I like this idea.  I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Michael Wouters]

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

But would it really solve your problems, Jim? The problem is essentially that periodically, there are two different clock times that represent the same moment in time. For telescopes, stock markets, spread spectrum, time-based encryption, etc that's a big problem. Would it not be better to separate out those entities that are more dependent on precision sequence than on clock time and accept that they are just going to be different? Yeah, the talking heads on CNBC and Bloomberg would gravely announce that today's stock market was opening a second later, but so what? At least there wouldn't be any more questions about exactly when transaction X occurred.
Bob
-----------------------------------------------------------------
AE6RV.com
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
Sent: Thursday, July 21, 2016 4:38 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)
The idea is the same as my local telco and their main exchanges.
Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in anger.
This leap second solution is the best I've heard so far.
Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it would
force the software problems to be fixed.
Jim Palfreyman

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Michael Rothwell]

Post by Michael Wouters
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.

No leap seconds seems preferable to more frequent leap seconds.

Post by Michael Wouters
Cheers
Michael

But would it really solve your problems, Jim? The problem is

essentially that periodically, there are two different clock times that
represent the same moment in time. For telescopes, stock markets, spread
spectrum, time-based encryption, etc that's a big problem. Would it not be
better to separate out those entities that are more dependent on precision
sequence than on clock time and accept that they are just going to be
different? Yeah, the talking heads on CNBC and Bloomberg would gravely
announce that today's stock market was opening a second later, but so
what? At least there wouldn't be any more questions about exactly when
transaction X occurred.

Bob
-----------------------------------------------------------------
AE6RV.com
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
To: Discussion of precise time and frequency measurement <
Sent: Thursday, July 21, 2016 4:38 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)
The idea is the same as my local telco and their main exchanges.
Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in

anger.

This leap second solution is the best I've heard so far.
Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it

would

force the software problems to be fixed.
Jim Palfreyman

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used

all

Post by Brooke Clarke
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific

worlds,

Post by Brooke Clarke

Post by Tom Holmes
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----

Behalf Of Tom Van

Post by Brooke Clarke

Post by Tom Holmes
Baak
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <

<javascript:;>>

Post by Brooke Clarke

Post by Tom Holmes
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of

this

Post by Brooke Clarke

Post by Tom Holmes
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS

decision

Post by Brooke Clarke

Post by Tom Holmes
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no

change

Post by Brooke Clarke

Post by Tom Holmes
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month

or

Post by Brooke Clarke

Post by Tom Holmes
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to

IERS

Post by Brooke Clarke

Post by Tom Holmes
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular

monthly

Post by Brooke Clarke

Post by Tom Holmes
event, instead of a rare, newsworthy exception. None of the weird bugs

we

Post by Brooke Clarke

Post by Tom Holmes
continue to see year after year in leap second handling by NTP and

OS's and

Post by Brooke Clarke

Post by Tom Holmes
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

and follow the instructions there.
_______________________________________________
To unsubscribe, go to

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Scott Stobbe]

If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

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" <***@gmail.com>
To: "Discussion of precise time and frequency measurement" <time-***@febo.com>
Sent: Thursday, July 21, 2016 3:06 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Scott Stobbe]

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.

Post by Tom Van Baak

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

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
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 -----
To: "Discussion of precise time and frequency measurement" <
Sent: Thursday, July 21, 2016 3:06 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used

all

Post by Scott Stobbe

Post by Brooke Clarke
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific

worlds,

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----

Van

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
Baak
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of

this

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS

decision

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no

change

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month

or

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to

IERS

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular

monthly

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
event, instead of a rare, newsworthy exception. None of the weird bugs

we

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
continue to see year after year in leap second handling by NTP and

OS's and

Post by Scott Stobbe

Post by Brooke Clarke

Post by Tom Holmes
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

Post by Scott Stobbe
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Brooke Clarke]

Hi Tom:

One of my interests is in Sun dials, so I like the idea of civil time corresponding as close as possible to the Sun's
position. Heliochronometers can be accurate to some seconds.
The Dent <http://www.prc68.com/I/Dent.shtml>Dipleidoscope <http://www.prc68.com/I/Dent.shtml> was used to set railroad
clocks based on the Sun's position.

Another area of interest is astronomy where UTC1 adds a correction to a tenth of a second to UTC that essentially
bridges the gap between the leap second corrections.
It would be interesting to learn how the Software Bisque Paramount telescope mount handles time. It does not have any
provision for a time nuts oscillator/clock, but maybe should?
--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

-------- Original Message --------

Post by Tom Van Baak

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Hi Scott,
The LSEM month suggestion retains the UTC policy of leaps being exactly +1 or -1 second, never larger, never smaller.
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 -----
Sent: Thursday, July 21, 2016 3:06 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Hi Brooke,

About sundials, timezones and "precise" timekeeping ...

There's a wonderful map by Stefano Maggiolo that everyone should look at:
Loading Image...

"How much is time wrong around the world?"
http://blog.poormansmath.net/how-much-is-time-wrong-around-the-world/


Someone mentioned the effect of leap seconds on true solar time. Based on the map, it's pretty common for civil noon (based on UTC) to be as much as an hour or more different from solar noon. Part of that is timezones. Part of that is DST. Part of that is seasonal, as in the equation of time (EoT). Given that, a +/-1 second offset due to a leap second is lost in the noise. In fact according to my EoT calculator the offset for today is 300 s and tomorrow its 309 s. So even one day's worth of EoT is ten times more than a leap second.

I would be interested in Sun dials too, maybe even a solar disciplined oscillator (SoDO), except most weeks it would be in holdover mode up here in the Northwest. ;-) The PID code would be quite interesting, since you can forward predict EoT. I think this is something Mike Cook would want to build, yes?

One other calculation for you: Earth circumference is 40,000 km. At 45 degrees latitude it's cos(45) = 0.707 as much. So an hour error from noon is 700 miles; a minute is 12 miles; a second is 1000 feet; and 1 ms is 1 foot; just like the speed of sound. That means a leap second is equivalent to walking 1000 feet, while DST is being forced marched 700 miles.

/tvb


----- Original Message -----
From: "Brooke Clarke" <***@pacific.net>
To: "Discussion of precise time and frequency measurement" <time-***@febo.com>
Sent: Friday, July 22, 2016 12:16 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Post by Brooke Clarke
One of my interests is in Sun dials, so I like the idea of civil time corresponding as close as possible to the Sun's
position. Heliochronometers can be accurate to some seconds.
The Dent <http://www.prc68.com/I/Dent.shtml>Dipleidoscope <http://www.prc68.com/I/Dent.shtml> was used to set railroad
clocks based on the Sun's position.
Another area of interest is astronomy where UTC1 adds a correction to a tenth of a second to UTC that essentially
bridges the gap between the leap second corrections.
It would be interesting to learn how the Software Bisque Paramount telescope mount handles time. It does not have any
provision for a time nuts oscillator/clock, but maybe should?
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Van Baak

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Hi Scott,
The LSEM month suggestion retains the UTC policy of leaps being exactly +1 or -1 second, never larger, never smaller.
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 -----
Sent: Thursday, July 21, 2016 3:06 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Brooke Clarke]

Hi Tom:

I'm not worried about a single second, but rather an accumulation of them over many years leading to making sundials
obsolete.

The map is centered on China (PS the Chinese symbol for china is a circle with a vertical line i.e. China is the center
of the world) and all of China is on the same time, they don't use time zones. Northern California looks pretty good.
Where I live there's a lot of solar panels because we get a lot of sun.

Almost all the corrections you mention are built into heliochronometers. I made a Noon mark by driving a brass tack
into a hardwood floor at exactly noon. After a few years you could see a group of three close together tacks for each
day because of the effect of leap years.
http://www.prc68.com/I/Sundial.shtml#Indoor_analemma

Yes, you need to know where on Earth you are in order to tell what time it is when using the sun.

I spent some time (TM: intended pun) looking into a way to use optical means to measure the Earth's period and the limit
is optical "seeing" which can amount to a few arc seconds of angle.
http://www.prc68.com/I/StellarTime.shtml
But I'm not convinced that a single optical observation defines the limit of precision. For example a fixed telescope
could time stamp each star meridian crossing and that data could be correlated with the known star positions to come up
with an averaged meridian crossing time. That would improve the accuracy by SQRT(# stars). So you might improve the
single shot observation error of 66 ms to maybe a hand full of ms. More than one fixed telescope could be used, &Etc.

I asked a scientist who works with the satellites that measure sea level how they can get the stated accuracy and the
answer was what I'd call massive averaging N=(tens of thousands).

I have a number of aircraft navigation instruments (Navigation, surveying & time are all areas I'm interested in) and
the MD1 Astro Compass may be able to track a star when mounted on a B-52 to better than 1 arc minute of angle. I
suspect better if mounted on a concrete pier on the ground. I've been told when mounted that way for testing it could
detect the deformation of the earth caused by a truck a mile away.
http://www.prc68.com/I/MD1.shtml
It's a marvel of mechanical and optical engineering. The sad thing is that the Air Force seems to burn all the manuals
for obsolete equipment. So far I have not been able to determine the electrical connections for the MD1.
--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

-------- Original Message --------

Post by Tom Van Baak
Hi Brooke,
About sundials, timezones and "precise" timekeeping ...
http://blog.poormansmath.net/images/SolarTimeVsStandardTime.png
"How much is time wrong around the world?"
http://blog.poormansmath.net/how-much-is-time-wrong-around-the-world/
Someone mentioned the effect of leap seconds on true solar time. Based on the map, it's pretty common for civil noon (based on UTC) to be as much as an hour or more different from solar noon. Part of that is timezones. Part of that is DST. Part of that is seasonal, as in the equation of time (EoT). Given that, a +/-1 second offset due to a leap second is lost in the noise. In fact according to my EoT calculator the offset for today is 300 s and tomorrow its 309 s. So even one day's worth of EoT is ten times more than a leap second.
I would be interested in Sun dials too, maybe even a solar disciplined oscillator (SoDO), except most weeks it would be in holdover mode up here in the Northwest. ;-) The PID code would be quite interesting, since you can forward predict EoT. I think this is something Mike Cook would want to build, yes?
One other calculation for you: Earth circumference is 40,000 km. At 45 degrees latitude it's cos(45) = 0.707 as much. So an hour error from noon is 700 miles; a minute is 12 miles; a second is 1000 feet; and 1 ms is 1 foot; just like the speed of sound. That means a leap second is equivalent to walking 1000 feet, while DST is being forced marched 700 miles.
/tvb
----- Original Message -----
Sent: Friday, July 22, 2016 12:16 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Post by Brooke Clarke
One of my interests is in Sun dials, so I like the idea of civil time corresponding as close as possible to the Sun's
position. Heliochronometers can be accurate to some seconds.
The Dent <http://www.prc68.com/I/Dent.shtml>Dipleidoscope <http://www.prc68.com/I/Dent.shtml> was used to set railroad
clocks based on the Sun's position.
Another area of interest is astronomy where UTC1 adds a correction to a tenth of a second to UTC that essentially
bridges the gap between the leap second corrections.
It would be interesting to learn how the Software Bisque Paramount telescope mount handles time. It does not have any
provision for a time nuts oscillator/clock, but maybe should?
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Van Baak

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Hi Scott,
The LSEM month suggestion retains the UTC policy of leaps being exactly +1 or -1 second, never larger, never smaller.
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 -----
Sent: Thursday, July 21, 2016 3:06 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

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

Post by Scott Stobbe
If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

Post by Brooke Clarke
I like this idea. I addresses the lesson from Y2K that something done
often works much better than something done only occasionally.
That's way you see the firetruck at the local store, because it's used all
the time and so is more likely to work when needed.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.
-------- Original Message --------

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require
either plus or minus 1 to work? Seems like you could stay closer to the
true value if you also have a zero option. Might also cause less
consternation for some services, like the finance and scientific worlds,
that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to
address issues promptly, and maybe that's the argument for the non-zero
option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement <
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC
December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this
would be a problem. The idea is not to decide *if* there will be leap
second, but to force every month to have a leap second. The IERS decision
is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
UTC, not so much by rare steps but by dithering. There would be no change
to UTC or timing infrastructure because the definition of UTC already
allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a
leap second, because bugs would be found by developers within a month or
two, not by end-users years or decades in the future, and 2) every
UTC-aware device would have an often tested direct or indirect path to IERS
to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly
event, instead of a rare, newsworthy exception. None of the weird bugs we
continue to see year after year in leap second handling by NTP and OS's and
GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era
where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
seconds a day, there will be zero impact if LSEM is already in place.
/tvb
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Hi Tom,

Post by Tom Holmes
Does your proposal allow for a Zero leap second

Nope, LSEM avoids the zero leap second situation. That's the idea: to always have a leap second. Either an add or a delete, at the end of every month. The beauty is that it wouldn't violate how UTC is already defined. Leap seconds would become a monthly normal instead of a rare event; that is, a regular pain in the ass instead of an exceptional pain in the ass [1].

Note that UTC would continue to stay within a second of UT1, so no problems there either. If you think about it, LSEM, like any fast dithering system, would actually create a better average value of UT1 than the existing slow step system. But that's not a goal; just a PWM side-effect.

There's more info in the original LSEM proposal and its long thread in the archives:

http://six.pairlist.net/pipermail/leapsecs/2010-November/001813.html

Post by Tom Holmes
Might also cause less consternation for some services, like the finance and
scientific worlds, that seem to have critical issues when an LS appears.

add to your list: airplanes, high-speed trains, telesurgery, self-driving cars, MRI machines ...

Yes, and that's the key question. And it's only getting worse. LSEM is not a random idea or a quick fix. As long as UTC has leap seconds (debatable) or as long as technology continues to depend on ever more precise time (likely) we have to make the handling of leap seconds as robust as the handling of, say, midnight rollover.

I realize it's probably too late in history to deploy. There's no right answer. LSEM is food for thought. Lots of people are and have been trying to avoid the long-term train wreck that the current definition and implementation of UTC will lead to. If you have time, read 15 years of our postings over on the leap second mailing list.

I think at this point, we should move the thread over to LEAPSECS alone, and give time-nuts a break. The cross-posting is getting confusing.

Thanks,
/tvb

[1] astronomical society specification ;-)


----- Original Message -----
From: "Tom Holmes" <***@woh.rr.com>
To: "'Discussion of precise time and frequency measurement'" <time-***@febo.com>
Cc: "'Leap Second Discussion List'" <***@leapsecond.com>
Sent: Thursday, July 21, 2016 12:03 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnightUTC December 31 this year

Post by Tom Holmes
Hi Tom...
Does your proposal allow for a Zero leap second, or does it require either plus or minus 1 to work? Seems like you could stay closer to the true value if you also have a zero option. Might also cause less consternation for some services, like the finance and scientific worlds, that seem to have critical issues when an LS appears.
I like your point that by having it occur monthly it forces systems to address issues promptly, and maybe that's the argument for the non-zero option.
Tom Holmes, N8ZM
-----Original Message-----
Sent: Thursday, July 21, 2016 1:28 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.
Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not so much by rare steps but by dithering. There would be no change to UTC or timing infrastructure because the definition of UTC already allows for positive or negative leap seconds in any given month.
Every UTC-aware device would 1) know how to reliably insert or delete a leap second, because bugs would be found by developers within a month or two, not by end-users years or decades in the future, and 2) every UTC-aware device would have an often tested direct or indirect path to IERS to know what the sign of the leap second will be for the current month.
The leap second would then become a normal part of UTC, a regular monthly event, instead of a rare, newsworthy exception. None of the weird bugs we continue to see year after year in leap second handling by NTP and OS's and GPS receiver firmware would occur.
Historical leap second tables would consist of little more than 12 bits per year.
Moreover, in the next decade or two or three, if we slide into an era where average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, there will be zero impact if LSEM is already in place.
/tvb

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Steve Allen]

Post by Tom Van Baak
Time to mention this again...
Every UTC-aware device would 1) know how to reliably insert or
delete a leap second, because bugs would be found by developers within
a month or two, not by end-users years or decades in the future, and
2) every UTC-aware device would have an often tested direct or
indirect path to IERS to know what the sign of the leap second will be
for the current month.

This idea pushes extra complexity into every implementation of low
level kernel-space software, firmware, and hardware. That's nice as a
policy for full employment of programmers, but it's hard to justify by
any other metric. Instead those low level places should be as simple
as possible, and that means making the underlying precision time
scale, and thus any broadcast distributions of a precision time scale,
as simple as possible.

The complexity for translating precision time in seconds (for
machines) to calendar time in days (for humans) belongs in the
less-critical and easier-testable outer layers of software which do
user-space presentation, internationalization, and GUI which can be
broadly shared between many hardware implementations.

--
Steve Allen <***@ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: [phone] Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Adrian Godwin]

I was inclined to agree, cynically reasoning that many implementations
would argue that the leapseconds would average out in most applications and
they could ignore them.

But actually, it would be good for programmers to properly separate the
concepts of elapsed time and clock-time. If elapsed time were handled by
kernels and clock-time handled by a user-mode UTC or calendar process, that
would be a cleaner solution with overhead only where needed (or where the
OS is big enough for it to be a trivial element).


As a side issue, what would be the impact of having frequent
leap-milliseconds instead of infrequent leap-seconds ?

Post by Steve Allen

Post by Tom Van Baak
Time to mention this again...
Every UTC-aware device would 1) know how to reliably insert or
delete a leap second, because bugs would be found by developers within
a month or two, not by end-users years or decades in the future, and
2) every UTC-aware device would have an often tested direct or
indirect path to IERS to know what the sign of the leap second will be
for the current month.

This idea pushes extra complexity into every implementation of low
level kernel-space software, firmware, and hardware. That's nice as a
policy for full employment of programmers, but it's hard to justify by
any other metric. Instead those low level places should be as simple
as possible, and that means making the underlying precision time
scale, and thus any broadcast distributions of a precision time scale,
as simple as possible.
The complexity for translating precision time in seconds (for
machines) to calendar time in days (for humans) belongs in the
less-critical and easier-testable outer layers of software which do
user-space presentation, internationalization, and GUI which can be
broadly shared between many hardware implementations.
--
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat
+36.99855
1156 High Street Voice: [phone] Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Post by Steve Allen
This idea pushes extra complexity into every implementation of low
level kernel-space software, firmware, and hardware. That's nice as a
policy for full employment of programmers, but it's hard to justify by
any other metric. Instead those low level places should be as simple
as possible, and that means making the underlying precision time
scale, and thus any broadcast distributions of a precision time scale,
as simple as possible.
The complexity for translating precision time in seconds (for
machines) to calendar time in days (for humans) belongs in the
less-critical and easier-testable outer layers of software which do
user-space presentation, internationalization, and GUI which can be
broadly shared between many hardware implementations.

Hi Steve,

Wow, that's most succinct two paragraph argument I've read for why we shouldn't have leap seconds at all. Where were you the past decade when this level of passion and clarity in the ITU debate was needed ;-)

/tvb
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Jay Grizzard]

Post by Steve Allen
This idea pushes extra complexity into every implementation of low
level kernel-space software, firmware, and hardware. That's nice as a
policy for full employment of programmers, but it's hard to justify by
any other metric. Instead those low level places should be as simple
as possible, and that means making the underlying precision time
scale, and thus any broadcast distributions of a precision time scale,
as simple as possible.

How does this make those things more complex, though? Those things are
already required to deal with both knowing about and adjusting the time
for leap seconds (both adding and removing, though adding is the only
direction that's ever been *tested*) ... increasing the frequency of the
announcements doesn't really add complexity there, except in places where
the code was already deficient (e.g. doesn't currently handle removing a
leap second, which is a bug).

If you wanted to do precise measurement of time between two dates, you'd
have to know about the number of leap seconds in between, but a) that's
easily done at a higher level than the kernel, and b) we already have to
do that to deal with existing leap seconds, just adding more datapoints to
the math doesn't actually make that more complex.

Am I missing something obvious where this would add complexity that isn't
already there?

-j
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Oz-in-DFW]

Post by Steve Allen

Post by Tom Van Baak
Time to mention this again...
Every UTC-aware device would 1) know how to reliably insert or
delete a leap second, because bugs would be found by developers within
a month or two, not by end-users years or decades in the future, and
2) every UTC-aware device would have an often tested direct or
indirect path to IERS to know what the sign of the leap second will be
for the current month.

This idea pushes extra complexity into every implementation of low
level kernel-space software, firmware, and hardware.

Why? That would only seem to be true if the leap second decision is
already made there. Most systems I'm aware do this in presentation
level firmware.

Post by Steve Allen
That's nice as a
policy for full employment of programmers, but it's hard to justify by
any other metric. Instead those low level places should be as simple
as possible, and that means making the underlying precision time
scale, and thus any broadcast distributions of a precision time scale,
as simple as possible.

I think I understand what you are saying, but I'm pretty sure I
disagree. The vast majority of complexity (and risk) of most software
and testing comes from exceptions and making sure all combinations are
tested. In this case the exception is simplified. You still need to
detect end of month, but you have regular logic to implement. As a
practical matter this should be easier to code as a fixed time of
execution operation.

Post by Steve Allen
The complexity for translating precision time in seconds (for
machines) to calendar time in days (for humans) belongs in the
less-critical and easier-testable outer layers of software which do
user-space presentation, internationalization, and GUI which can be
broadly shared between many hardware implementations.

I agree for the most part. Complexity should be driven as high in the
layer stack as practical. What about this proposal requires changes
from the place it is already done in a particular system?
--
mailto:***@ozindfw.net
Oz
POB 93167
Southlake, TX 76092 (Near DFW Airport)



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Gregory Maxwell]

Post by Tom Van Baak
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.

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.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Martin Burnicki]

Post by Tom Van Baak
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of
this would be a problem. The idea is not to decide *if* there will be
leap second, but to force every month to have a leap second. The IERS
decision is then what the *sign* of the leap second should be this
month.

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

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Heiko Gerstung]

Post by Martin Burnicki

Post by Tom Van Baak
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of
this would be a problem. The idea is not to decide *if* there will be
leap second, but to force every month to have a leap second. The IERS
decision is then what the *sign* of the leap second should be this
month.

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

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

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

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

Post by Martin Burnicki

Post by Tom Van Baak
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of
this would be a problem. The idea is not to decide *if* there will be
leap second, but to force every month to have a leap second. The IERS
decision is then what the *sign* of the leap second should be this
month.

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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Martin Burnicki]

Bob,

Post by Bob Camp
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.

But if you

- stick with the leap seconds with UTC as-is
- let the kernel alternatively run on TAI instead of UTC
- keep existing API calls as they are, returning UTC
- introduce new API calls which tell if the kernel runs UTC or TAI
and let you query the TAI time stamps

then both kernels and applications could make a change over to the new
timekeeping seamlessly.

I agree this wouldn't fix all problems you may have with leap seconds,
but it would at least avoid problems like "the kernel hangs when the
system time is stepped back by 1 s to account for a leap second".

Martin

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

Hi

Post by Martin Burnicki
Bob,

Post by Bob Camp
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.

But if you
- stick with the leap seconds with UTC as-is
- let the kernel alternatively run on TAI instead of UTC
- keep existing API calls as they are, returning UTC
- introduce new API calls which tell if the kernel runs UTC or TAI
and let you query the TAI time stamps
then both kernels and applications could make a change over to the new
timekeeping seamlessly.
I agree this wouldn't fix all problems you may have with leap seconds,
but it would at least avoid problems like "the kernel hangs when the
system time is stepped back by 1 s to account for a leap second”.

Except that you still have the issue of “what time did this file get changed”. To most of us, that’s not
really a big deal. A second either way … who cares. :) In some areas they care a *LOT* and a second
is a really big deal. Having two different time stamps running around in the same kernel with different
people picking which one to use …. sounds like a recipe for trouble.

Now, having the “new” calls ahead of the transition, yes, that’s pretty much mandatory. You do need to
debug this stuff and it has to be done somehow. If we are talking about the original suggestion, it’s a one
second delta one way or the other. There is nothing going on below the second level. I suppose you *could*
have more than one second, but it seems unlikely. In that case, your call is pretty simple “give me the delta”.
Seems fairly easy / safe. I’ve messed up things that are far simpler :)

Bob

Post by Martin Burnicki
Martin
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mike Cook]

Post by Tom Van Baak
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second should be this month.

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.
***@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.

Post by Tom Van Baak
/tvb
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Noah]

First time poster; just subbed. Not a time hobbies the; my team @ work runs NTP infrastructure. So , that's a brief intro out of the way...

Discovered that my commercial GPS appliances opted to *apply* yesterday's pending leap second, which has made for an interesting day.

--n

Post by Jay Grizzard

Post by Mark Sims
The GPS satellites are now reporting the pending leapsecond...
The Z3801A has it messed up... it says the leap will occur on 30 Sep
2016 (73 days). The Z3801A has two different messages that report the
leap day... both are wrong.

I think some (modern!) Trimble gear may also has a problem. I have an ICM
SMT 360 board that's (slowly) flipping back and forth between showing a UTC
offset of 17 seconds and an offset of 18 seconds. This is their currently
shipping timekeeping chip, so it's surprising, but I don't know how else
to explain the behavior outside of a firmware bug.
(I've sent an email to Trimble support, but haven't heard anything back yet.)
-j
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Gary E. Miller]

Yo Noah!

On Wed, 20 Jul 2016 17:12:14 -0400

Post by Noah
work runs NTP infrastructure. So , that's a brief intro out of the
way...

Yes, a few of us NTP people here. We are several orders of magnitude
coarser tham a true time-nut.

Post by Noah
Discovered that my commercial GPS appliances opted to *apply*
yesterday's pending leap second, which has made for an interesting
day.

Got any details? GPS model? Did it get past your NTP into system time?

I'm passing this info onto NTPsec devel folks. Time to 'Name and Shame".

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
***@rellim.com Tel:[phone]

[Noah]

Trimble Res-SMT-GG GNSS receivers are affected; in my case, they're installed in Spectracom SecureSyncs. And yes, the extra second got into system time which broke 1 or 2 things.

--n

Post by Gary E. Miller
Yo Noah!
On Wed, 20 Jul 2016 17:12:14 -0400

Post by Noah
work runs NTP infrastructure. So , that's a brief intro out of the
way...

Yes, a few of us NTP people here. We are several orders of magnitude
coarser tham a true time-nut.

Post by Noah
Discovered that my commercial GPS appliances opted to *apply*
yesterday's pending leap second, which has made for an interesting
day.

Got any details? GPS model? Did it get past your NTP into system time?
I'm passing this info onto NTPsec devel folks. Time to 'Name and Shame".
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

Post by Noah
Discovered that my commercial GPS appliances opted to *apply* yesterday's
pending leap second, which has made for an interesting day.

Could you please say more?

How are you working around it?

Vendor? Model? Can you take the cover off (or peer in through the vents)
and see what type of GPS receiver they are using?

I assume the gear is recent or the problem would have been discovered the
last time we had a leap second. Have you contacted the vendor? Have they
confirmed the problem? Any estimate on when they will ship new firmware?

Has anybody else noticed the problem? (I tried google news and NANOG but
didn't find anything.)

[Noah]

Post by Hal Murray

Post by Noah
Discovered that my commercial GPS appliances opted to *apply* yesterday's
pending leap second, which has made for an interesting day.

Could you please say more?
How are you working around it?
Vendor? Model? Can you take the cover off (or peer in through the vents)
and see what type of GPS receiver they are using?

In earlier email.

Post by Hal Murray
I assume the gear is recent or the problem would have been discovered the
last time we had a leap second. Have you contacted the vendor? Have they
confirmed the problem? Any estimate on when they will ship new firmware?

We just finished replacing our previous gear with this a week ago; timing is everything. :) Vendor was contacted yesterday and have supplied a patch this morning to reduce the GPS->UTC offset back to 17 until they get a more permanent fix from Trimble. I've not installed it yet, but the vendor states the patch won't persist across reboots.

--n
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Noah]

Follow up: Spectracom has released an official document which broadens the known impact to include their Accutime GG antenna:

http://support.spectracom.com/articles/FAQ/Why-is-there-a-1-second-time-error-from-my-GPS-reference

Post by Noah

Post by Hal Murray

Post by Noah
Discovered that my commercial GPS appliances opted to *apply* yesterday's
pending leap second, which has made for an interesting day.

Could you please say more?
How are you working around it?
Vendor? Model? Can you take the cover off (or peer in through the vents)
and see what type of GPS receiver they are using?

In earlier email.

Post by Hal Murray
I assume the gear is recent or the problem would have been discovered the
last time we had a leap second. Have you contacted the vendor? Have they
confirmed the problem? Any estimate on when they will ship new firmware?

We just finished replacing our previous gear with this a week ago; timing is everything. :) Vendor was contacted yesterday and have supplied a patch this morning to reduce the GPS->UTC offset back to 17 until they get a more permanent fix from Trimble. I've not installed it yet, but the vendor states the patch won't persist across reboots.
--n

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Wojciech Owczarek]

Every year... always makes me wonder, do these vendors even test this themselves? I know at least one vendor who disn't have GPS simulators and relied on Trimble's built-in test mode - which gives you 13-bit week counters, whereas the satellites give you 10-bit counters. So the vendor assumed 13-bit and was comparing the current wc to 13-bit that never came. Luckily I found the issue months before the event, and only because we purchased GPS simulators - which I recommend to anyone running timing services in production.

Oh well, at least this keeps us busy.


  Original Message  
From:***@gmail.com
Sent:21 July 2016 5:11 p.m.
To:time-***@febo.com
Reply to:time-***@febo.com
Cc:***@megapathdsl.net
Subject:Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Post by Hal Murray

Post by Noah
Discovered that my commercial GPS appliances opted to *apply* yesterday's
pending leap second, which has made for an interesting day.

Could you please say more?
How are you working around it?
Vendor?  Model?  Can you take the cover off (or peer in through the vents)
and see what type of GPS receiver they are using?

In earlier email.

Post by Hal Murray
I assume the gear is recent or the problem would have been discovered the
last time we had a leap second.  Have you contacted the vendor?  Have they
confirmed the problem?  Any estimate on when they will ship new firmware?

We just finished replacing our previous gear with this a week ago; timing is everything. :)  Vendor was contacted yesterday and have supplied a patch this morning to reduce the GPS->UTC offset back to 17 until they get a more permanent fix from Trimble. I've not installed it yet, but the vendor states the patch won't persist across reboots.

--n
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

Apple's new file system timestamps files with nanosecond resolution. A lot of Linux file systems also do that now. The nanosecond ain't what it used to be... I can imagine people wanting picosecond timestamps in the near future. Who knows, maybe we'll have something like NTP compensating for light-speed delay for the gap between the read/write heads and disk surface (assuming we still use heads and surfaces) ; -)
--------------------
Except that you still have the issue of “what time did this file get changed”. To most of us, that’s not really a big deal. A second either way … who cares.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

Hi

In these days of computers trading with computers, the whole issue of “who did what when” can
result in major money trading hands. I’m sure that at some point the financial markets will have to
deal with light speed issues and geography if they have not already.

Bob

Post by Mark Sims
Apple's new file system timestamps files with nanosecond resolution. A lot of Linux file systems also do that now. The nanosecond ain't what it used to be... I can imagine people wanting picosecond timestamps in the near future. Who knows, maybe we'll have something like NTP compensating for light-speed delay for the gap between the read/write heads and disk surface (assuming we still use heads and surfaces) ; -)
--------------------
Except that you still have the issue of “what time did this file get changed”. To most of us, that’s not really a big deal. A second either way … who cares.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[bownes]

We've been dealing with speed of light issues for over 20 years in the financial world. And telecom.

Someone recently built a new fiber route from Chicago to NY because it was just a touch shorter. The distances are down to hundredths of a ms.

Post by Bob Camp
Hi
In these days of computers trading with computers, the whole issue of “who did what when” can
result in major money trading hands. I’m sure that at some point the financial markets will have to
deal with light speed issues and geography if they have not already.
Bob

Post by Mark Sims
Apple's new file system timestamps files with nanosecond resolution. A lot of Linux file systems also do that now. The nanosecond ain't what it used to be... I can imagine people wanting picosecond timestamps in the near future. Who knows, maybe we'll have something like NTP compensating for light-speed delay for the gap between the read/write heads and disk surface (assuming we still use heads and surfaces) ; -)
--------------------
Except that you still have the issue of “what time did this file get changed”. To most of us, that’s not really a big deal. A second either way … who cares.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[bownes]

A second here or there is a very big deal to those of us in the financial and database worlds.

Aside from the well known instances involving electronic trading I have customers fighting over cabinet positions and cable lengths to place processors closer to disk drives and on switch paths with 10ns less latency.

Post by Mark Sims
Apple's new file system timestamps files with nanosecond resolution. A lot of Linux file systems also do that now. The nanosecond ain't what it used to be... I can imagine people wanting picosecond timestamps in the near future. Who knows, maybe we'll have something like NTP compensating for light-speed delay for the gap between the read/write heads and disk surface (assuming we still use heads and surfaces) ; -)
--------------------
Except that you still have the issue of “what time did this file get changed”. To most of us, that’s not really a big deal. A second either way … who cares.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Michael Wouters]

I'd be interested to know how 10ns less latency is useful. AFAIK, a high
speed trading system consists of multiple processing nodes, which certainly
could have a 10ns accurate time reference eg via PTP, but latency and
jitter would limit time stamping of transactions to the microsecond level.
Unless of course, the critical bits are all running on dedicated hardware.

Cheers
Michael

Post by bownes
A second here or there is a very big deal to those of us in the financial
and database worlds.
Aside from the well known instances involving electronic trading I have
customers fighting over cabinet positions and cable lengths to place
processors closer to disk drives and on switch paths with 10ns less latency.

Post by Mark Sims
Apple's new file system timestamps files with nanosecond resolution. A

lot of Linux file systems also do that now. The nanosecond ain't what it
used to be... I can imagine people wanting picosecond timestamps in the
near future. Who knows, maybe we'll have something like NTP compensating
for light-speed delay for the gap between the read/write heads and disk
surface (assuming we still use heads and surfaces) ; -)

Post by Mark Sims
--------------------
Except that you still have the issue of “what time did this file get

changed”. To most of us, that’s not really a big deal. A second either way
… who cares.

Post by Mark Sims
_______________________________________________
To unsubscribe, go to

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

Post by Mark Sims
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

And somebody paid well over 10 times the market rate to lease server space that was one building closer to the NYSE computers. My idea to put an end to this bogo-trading nonsense is to add a random delay to all the trades.

------------------------

Post by bownes
Someone recently built a new fiber route from Chicago to NY because it was just a touch shorter. The distances are down to hundredths of a ms.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

The systems collecting the data have 200-300 microsec peak-peak of
clock offset, mostly tracking daily temperature swings.

How do you know that?

Which "that"?

I don't have a formal proof, just a collection of data that all fits together.

You can get the clock offset from loopstats. That can lie, for example by using a PPS over USB without fudging to correct for the USB polling delay or getting the time from the net with asymmetric delays due to routing or last-mile link speeds.

You can confirm things by using a good NTP system to monitor your targets. That's somewhat circular since you have to ask how good is the clock on your "good" system.

You can get the temperature connection by plotting offset and temperature over 24-48 hours. You can get confirmation by plotting the drift.

Crystals are well known to have a temperature effect so the drift-temp connection shouldn't be surprising.

On Linux, you can get the temperature from
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
or similar. The filename depends slightly on the version of the kernel you are using.

You can get confirmation of the temperature from the disk using hddtemp or smartd and/or by monitoring your room temperature. (That works better if the disk is in the same box.)

You would really like to measure the temperature at the crystal. I haven't gone that far.

[Hal Murray]

So, you have plotted offset versus temp? Can we see that?

I don't have offset vs temperature. This is what I work with:
Loading Image...
Loading Image...

Scan the wiki page for PID controllers:
https://en.wikipedia.org/wiki/PID_controller

Consider the simple case (no I, no D). If you have a constant rate of
temperature change, there is a stable point with a constant offset. The
offset keeps adjusting the frequency (drift in ntp speak) to track the
temperature. The offset and temp derivative are related by the gain.

The graphs aren't great, but when the temperature is going up the offset is
positive and the reverse.

I would not be surprised if temp was dominant here. But I can think of a
few other things that may be dominant instead.

Such as?

I would only consider CPU temp a very rough proxy for XTAL temp. Room
ambient would be much closer to XTAL temp.

That box is fanless. (There is actually a tiny fan under the disk.) Mostly,
it's not doing any work.

Room temp tracks CPU temp.

Yup. I have some USB thermometers that are good for such things.

Model? URL?

[Rick Jones]

Post by Hal Murray

Yup. I have some USB thermometers that are good for such things.

Model? URL?

Might be over-spec'ed or simply reflect a lack of broad evaluation on
their part, but the SPEC folks have an accepted device list for
temperature sensors to be used for measuring ambient temps for
SPECpower(tm) benchmarks:

https://www.spec.org/power/docs/SPECpower-Device_List.html#mozTocId276706

rick jones

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

I have added some code to my message time offset measurement routine to calculate a histogram of the values (along with the average and standard deviation). I'm now using the peak histogram bin(s) to determine the message offset time. The histogram technique has the advantage of ignoring outlier points that can be caused by the system being tied up / interrupted doing other things (like shoving a Windows 10 upgrade up your systems' rear I/O port ;-()
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

With care I can measure GPS jitter on a RasPi to a bit over 300 nano sec
resolution. That is the smallest increment of the RasPi 3B clock with a
64-bit kernel. That is clearly not time-nuts accuracy.
What would you guys suggest as the cheapest way to see jitter down to around
1 nano second?

What do you mean by "jitter" and what do you really want to do?

Jitter usually needs a reference. Do you have one?

I'm thinking maybe something like a rubidium standard (FE-5680A) and a
TICC-TAPR? But that would put me out around $400.

Do you have a scope?

The Rigol DS1102E is/was quite popular and is good for close to a ns. I got
mine several years ago for $400. Looks like the going price is closer to
$300 now. It's got a USB port. You can read the data and decode it in
software.

They make lots of similar scopes. The middle 2 digits are the bandwidth: 5=>
50MHz, 10=>100MHz. The last digit is the number of channels.)

The chip in the BeagleBone series boards has extra CPUs that help with things
like this. I don't know how fast they go. I haven't seen 64 bit versions or
a lot of software activity.

[Hal Murray]

The results were disappointing. See attached. For 8x the price all I see
is a slightly flatter ADEV curve.

What were you expecting?

How good is your antenna? Can you insert an attenuator and compare them
again? It would also be interesting to see the NEO-M8N with good vs bad
antenna.

As Bob suggests, it will be interesting to see what happens after you apply
sawtooth correction.

The M8T also support raw data, so I can try to use it for RINEX files.

It would be interesting to see how well the RINEX location compares with the
surveyed location and/or if using the RINEX location improves the timing
output.