[time-nuts] Re: Another leap second problem

[Bob Camp]

Hi

At this point, GPS has been around for quite a while. Various timing receivers have also been around for quite a while as a result. Many of the old ones have been past EOL / without firmware updates for decade(s). Bugs in this or that code in this or that device have been a fact of life for a very long time. 
This may be a combination of hardware plus firmware, verifying that this or that example has issues  may not have broad implications. Possibly microscope inspection would sort out the hardware. That’s rarely a practical approach. The information about serial numbers mapping to hardware mods …. long gone. 

The most basic answer is to let the GPS run in as a PPS source to your NTP. Get your time of day and date “somewhere else”. No that’s not a perfect answer. It does take out a lot of the issues on older stuff. 

These days, multi GNSS modules and devices are all over the place. You can “get time” from multiple systems. Doing that can take out many of the bug issues. At the very least, you have a way to cross check the data.

There will always be folks out there who make mistakes in code. There always will be “escapes” from the code testing process. No, it’s not any fun to explain to your customer. I have empirical data on this …

With the NTP pool as a source, you really don’t know what’s on the other end. It could be 40+ year old hardware (but running very well). It could be a “home lab” setup run by just about anybody. There have been “fun” issues because of that mix for a very long time. Unless there is a fundamental change (which I’m not advocating…) they will be with us in the future. 

Bob

 

> On Nov 10, 2025, at 1:44 AM, trv-n via time-nuts <time-nuts at lists.febo.com> wrote:
> 
> Hello,
> 
> Recently I have used the HackRF One and github.com/osqzss/gps-sdr-sim to test leap handling with Trimble smart antennas. I was able to determine that the Palisade and Acutime 2000 have the mentioned 256-week problem (they were setting their "leap pending" bits back in January of this year).  I just checked an Acutime 2000 and its leap pending bit is set, but newer versions of ntpd will filter it out until next month.
> 
> Although they still work with ntpd (thanks to its automatic WNRO correction), I think that it is very unlikely anyone is using a Palisade or Acutime 2000 with the time server pool so it's probably not the cause of the incident.
> -- Trevor
> 
> On 11/8/2025 8:39 AM, Tom Van Baak via time-nuts wrote:
>> Hi Steven,
>> The GPS spec is fine, although leap second calculations are a bit tricky. Almost all GPS receivers get it right but there's a bug in some that's triggered when there have been no leap seconds for more than 256 weeks, or in this case, 512 weeks. Details at [1].
>> The most recent leap second was at the end of 2016-12-31, which was in GPS week 1877 (GPS weeks count from 1980-1-6). The bogus date you quote, 2025-10-25, is in GPS week 2389. Note that 2389 - 1877 = 512. So yes this is another instance of the same receiver f/w bug.
>> Let us know when they identify which make/model receiver it is, and what protocol it is speaking.
>> But while I have your attention, it's also a bug in NTP. The definition of UTC says if a leap second occurs it will be the last day of the month, and the date you quote, 2026-10-25, isn't the last day. So NTP appears to be missing basic range checking. That you can easily fix if you know who maintains NTP or NTP-like software.
>> A cheap GPS simulator would be nice, but in this case you can simply manipulate the serial protocol stream to test how NTP reacts to bogus data.
>> /tvb
>> [1] http://leapsecond.com/notes/leapsec256.htm
>> On 11/7/2025 4:47 PM, Steven Sommars via time-nuts wrote:
>>> Recently a popular NTP/GNSS server began displaying an upcoming leap second
>>> notice  <https://community.ntppool.org/t/leap-second-in-october-2026/4132/8>
>>> .
>>> That date is slightly less than 351 days in the future.  If my math is
>>> correct,that corresponds to Sunday, 2026-10-25 00:00:00.
>>> The NTP server support team has reproduced the problem and is investigating.
>>> 
>>> There was a leap seconds incident
>>> <https://community.ntppool.org/t/leap-indicator-set-beginning-2021-11-27-00-00/2253>in
>>> 2021. Look at these dates:
>>> 
>>> 1792886400 2026-10-25 00:00:00  Date advertised by NTP server.   (first
>>> column is seconds since Unix Epoch)
>>> 
>>> 1638057600 2021-11-28 00:00:00   Another leap seconds incident
>>> <https://community.ntppool.org/t/leap-indicator-set-beginning-2021-11-27-00-00/2253>
>>> 
>>> 
>>> 1483228800. 2017-01-01 00:00:00  Previous leap second
>>> 
>>> These dates are each separated by 256-weeks.    There is a description of a
>>> 256-week bug at http://www.leapsecond.com/notes/leapsec256.htm
>>> 
>>> How widespread is this?   Commercial grade GPS simulators are expensive.
>>> Could one build an SDR-based simulator on the cheap to test for such
>>> problems?
>>> 
>>> Steve Sommars
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com