> 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 have a leap second. T
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 wrote:
>
>
>
>> On Jul 21
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 have a leap second. The
-Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
> Sent: Thursday, July 21, 2016 1:28 PM
> To: Discussion of precise time and frequency measurement
> Cc: Leap Second Discussion List
> Subject: Re: [time-nuts] Leap second to
es, N8ZM
>
>
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
> Sent: Thursday, July 21, 2016 1:28 PM
> To: Discussion of precise time and frequency measurement
> Cc: Leap Second Discussion List
> Subject: Re: [t
o.com] On Behalf Of Tom Van Baak
Sent: Thursday, July 21, 2016 1:28 PM
To: Discussion of precise time and frequency measurement
Cc: Leap Second Discussion List
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December
31 this year
Time to mention this again...
If we adopte
al Message
From:noah.ro...@gmail.com
Sent:21 July 2016 5:11 p.m.
To:time-nuts@febo.com
Reply to:time-nuts@febo.com
Cc:hmur...@megapathdsl.net
Subject: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:
>
>
>
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 shoul
> 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 you working around it?
>
>
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 ven
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 17:12:14 -0400
> N
> 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. However, the *time* it has
>> *output* should not
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
coarser tham a true tim
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
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, 20
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. However, the *time* it has
> *output* should not have jumped back and forth by 1 second.
I have a report of a Venus8, w
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
>>
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 wro
> 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 and September.
>
> So
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 is false. Don't ever
h
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 authoritie
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 code
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?
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
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 c
ot;Discussion of precise time and frequency measurement"
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!
> > IERS is free to schedule a leap second at the end of any month. And
> > it may be an
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 this assumption.
>
> >
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 referenc
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 reference for that? I know many people tha
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 assumption.
NTP Classic thi
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.
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 h
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 d
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 leap-pe
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.
__
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. )
>
>
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 "host
As NTP comes up here quite a bit :
The IERS have recently issued a new Bulletin C indicating that a Leap Second
will be added at the end of December this year.
The Bulletin C can be seen at <
https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat >
The relevant NTP leap-seconds-list file can be do
38 matches
Mail list logo