[time-nuts] Re: Another leap second problem

[Magnus Danielson]

Hi,

I agree that NTP has a problem here. It should indeed check that it is a 
valid date, i.e. end of a UTC month.

Now, there is receiver specific bugs, that made a range of GPSDOs assume 
it was the end of current UTC quarter just because it saw the 
leap-second flag, but ended up not reading out the details from the 
receiver, so the actual receiver knew correctly. Bugs like that needs to 
be specific to receivers to overcome problems.

However, NTPD have sometimes misunderstood GPS roll-over issues to be 
receiver bugs, while it is really a form of misfeature affecting any GPS 
L1 C/A only receiver. Later signals such as L5, L2C etc. have this fixed 
as they added another three bits of GPS week, so rollover is at 8192 weeks.

The lesson being, there is multiple places where mistakes can be done, 
and one needs to be a bit humble about this as one can too easy trust a 
source, or too easy dismiss a source and neither are good. For instance, 
a GPS rollover only make the date portion of the processing provide 
incorrect information, however the receiver keeps correcting for 
leap-second information correctly since it is not expressed and dialed 
as a normal date, but assigned in GPS format.

With modern receivers, many of these issues are gone. We do not need a 
GPS/GNSS simulator for testing, as we can rather just simulate their 
serial port protocols as we know what mess we can cause there. There is 
an overbelief in using the NMEA strings over the dedicated protocol, 
which can often provide much better information and avoid unambiguity. 
Setting up say a RPi to sit inbetween a receiver and the rest of the 
GNSSDO and simulate the protocol & mess with protocols is relatively 
simple and would enable a type of debugging that would be really handy. 
This could also be used to replace old receivers with new ones.

Cheers,
Magnus

Den 2025-11-08 kl. 14:39, skrev Tom Van Baak via time-nuts:
> 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