[time-nuts] Re: Another leap second problem

[Jonathan Rawlinson]

Hi all,

Yep - leap seconds always add to the fun here!

@Steve re cheap GPS simulators - I keep meaning to have a play with
"GPS-SDR-SIM" with some cheaper SDRs (Pluto board, HackRF, etc) - it looks
really well structured (although sadly has now been marked as archived by
the author!)
https://github.com/osqzss/gps-sdr-sim

To get good results, the SDR will need to have good local oscillator -
Nooelec sell a TCXO upgrade kit for the HackRF for example (as the factory
fitted one is not great):
https://www.nooelec.com/store/tiny-tcxo.html

Thanks

Jonathan


On Sat, Nov 8, 2025 at 1:50 PM Tom Van Baak via time-nuts <
time-nuts at lists.febo.com> 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
>