[time-nuts] Re: Another leap second problem

[trv-n]

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