[time-nuts] Re: Another leap second problem

Steven Sommars stevesommarsntp at gmail.com
Sun Nov 9 01:04:35 UTC 2025 

There are many simplifications. Feel free to correct errors.
For the most part this topic is a GPS concern, since non-NTP clients may be
affected.
NTP discussions are best pursued elsewhere.

Combining responses to several comments...

        The link provided does not seem to go to a good description of the
problem. Is there a better
        link? This could be a coding issue in NTP and have very little to
do with GPS.
I wrote an NTP-centric note about the 2021 incident.
  https://weberblog.net/partial-ntp-pool-the-leap-second-that-wasnt/
Tom's 256-week article describes the GPS interpretation issue. Also see

https://berthub.eu/articles/posts/leapseconds-expose-bugs-even-when-they-dont-happen/
There were a couple of related time-nuts threads in November 2021.

NTP is responsible for delivering UTC plus the leap second status (Leap
Indicator,
sometimes called a leap second warning) to its clients.
The GPS device is responsible for delivering the same information to NTP.
NTP *may* get leap second status information from other sources.
In some configurations GPS and NTP are distinct, in others they are
intertwined.
E.g., there are device specific drivers for some GPS hardware within ntpd's
reference clock suite.
I prefer keeping the device specific code inside a separate program such
gpsd(gpsd.gitlab.io)

If the GPS device delivers incorrect UTC to NTP and NTP has other time
sources, NTP
may be able to detect the problem and tag GPS as the falseticker.  If the
only NTP time source
(as in some low cost NTP/GPS appliances), then NTP will deliver incorrect
time.
The incorrect time values will be implementation dependent.

        GPS simulator:  https://github.com/osqzss/gps-sdr-sim
Thanks for the pointer.  [I see used Spectracom simulators on eBay for
$1000-$2000.  This is above my hobbyist budget.]

With 11 months of warning the community has time to discover latent issues
and fix the GPS or be prepared for the ramifications.
Ideally the responsible developers (or the broader technical community)
 would test the units and document the results.

        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.
This is already covered by some NTP implementations, see below.
GPS issues may not be exposed by simulating a NMEA serial interface.

        Let us know when they identify which make/model receiver it is, and
what
        protocol it is speaking.
LeoNTP Time Server 1200.  Google says it is a 72-channel u-blox M8, I
haven't verified.
The LeoNTP leap second note does not tell us what will happen on 2026-10-25.

        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.
This is a robustness consideration, not a NTP bug.  Previous leap seconds
occurred at the
end of December and June. [Who knows whether standards/specifications
permit leap seconds at the end of the other ten months?]
Some of the major implementations, classic NTP(nwtime.org), NTPsec, chrony,
already contain logic that limits leap seconds to the end of a month.
Time server appliances and other less common software implementations may
lack such robustness checks.

This bug is in some GPS client implementations, not a bug in the GPS
specification or the GPS infrastructure.


On Sat, Nov 8, 2025 at 7:50 AM 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
>

More information about the Time-nuts_lists.febo.com mailing list