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

> Le 21 juil. 2016 à 19:27, Tom Van Baak a écrit : > > 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

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

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 > On Jul 21, 2016, at 12:02 PM, Noah

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

On Thu, Jul 21, 2016 at 5:27 PM, Tom Van Baak wrote: > 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

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

Hi Tom, > 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

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

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 > On Jul 21, 2016, at 3:03 PM, Tom Holmes

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

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

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

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

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

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

> On Jul 21, 2016, at 5:23 AM, Hal Murray wrote: > > > noah.ro...@gmail.com said: >> 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

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

noah.ro...@gmail.com said: > 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

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

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 > On Jul 20, 2016, at 5:26 PM, Gary E. Miller wrote: > > Yo Noah! > > On Wed, 20 Jul 2016

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

> Le 20 juil. 2016 à 22:10, Gary E. Miller a écrit : > > Yo Martin! > > On Wed, 20 Jul 2016 21:37:02 +0200 > Martin Burnicki wrote: > >> So when the GPS receiver always just *showed* information on the >> current UTC data set then this is OK.

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

Yo Noah! On Wed, 20 Jul 2016 17:12:14 -0400 Noah wrote: > 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... Yes, a few of us NTP people here. We are several orders of magnitude

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

On Wed, Jul 20, 2016 at 09:37:02PM +0200, Martin Burnicki wrote: > 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

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

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 >> On Jul 19,

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

Jay Grizzard wrote: > On Tue, Jul 19, 2016 at 11:39:29PM +, Mark Sims wrote: >> 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

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

On Tue, Jul 19, 2016 at 11:39:29PM +, Mark Sims wrote: > 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

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

> On Jul 20, 2016, at 12:25 AM, Tom Van Baak wrote: > > 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

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

Gary E. Miller wrote: > Yo time-nuts@febo.com! > > On Tue, 19 Jul 2016 23:18:18 -0700 > Hal Murray , time-nuts@febo.com wrote: > >> g...@rellim.com said: In general there's a common belief that a leap second can only occur at the end of June or December. This

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

Magnus, Magnus Danielson wrote: > 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

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

Hi Hal, I guess you know this but... > 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

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

On Wed, Jul 20, 2016 at 01:05:59AM -0700, Hal Murray wrote: > g...@rellim.com said: > > 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?

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

Hal Murray wrote: > g...@rellim.com said: >>> 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: > > I wasn't considering refclocks

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

g...@rellim.com said: > 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? g...@rellim.com said: >> I don't think there is anything in the

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

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

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

Yo time-nuts@febo.com! On Tue, 19 Jul 2016 23:18:18 -0700 Hal Murray , time-nuts@febo.com wrote: > g...@rellim.com said: > >> 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

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

Gary, On 07/20/2016 07:36 AM, Gary E. Miller wrote: Yo Tom! 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

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

Yo Tom! Here we go again. Leap seconds always cause stress... On Tue, 19 Jul 2016 22:08:48 -0700 "Tom Van Baak" wrote: > 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

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

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

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

hol...@hotmail.com said: > I get the Z3801A leap pending flag from the #T1 or #T2 time stamp in the > :PTIM:TCOD? response. I see it now. Started a bit after an hour UTC into the new day. 57589 4546.033 127.127.26.1 T22016072001154730+0038 64 0 So either I didn't look carefully enough or it

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

I get the Z3801A leap pending flag from the #T1 or #T2 time stamp in the :PTIM:TCOD? response. For the date, either :PTIM:LEAP:DATE? or :PTIM:LEAP:GPST? depending upon the unit type. And now for some more receiver leapsecond shenanagins: The Ublox receivers work well. You can calculate the

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

hol...@hotmail.com said: > 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. Which messages are you looking at? There is a

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

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.

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

Hal Murray wrote: > > michael.c...@sfr.fr said: >> The relevant NTP leap-seconds-list file can be downloaded with anonymous ftp >> from the pub directory at time.nist.gov. (The leap-seconds-list file is a >> symbolic link to the data file leap-seconds.3676924800 in the same >> directory. ) > >

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

michael.c...@sfr.fr said: > The relevant NTP leap-seconds-list file can be downloaded with anonymous ftp > from the pub directory at time.nist.gov. (The leap-seconds-list file is a > symbolic link to the data file leap-seconds.3676924800 in the same > directory. ) The NIST servers at that