[time-nuts] Re: Another leap second problem

[Steven Sommars]

An adaptation layer between the GPS and UTC time scales exists *somewhere *in
a UTC/GPS-delivering entity.  That entity must cope with GPS WN, leap
seconds and the like.
That layer is not part of the NTP specification, but might be implemented
within a GPS chip, in a time appliance's CPU, or even in device specific
modules within some NTP implementations.

*Leap second warning*.   Some NTP implementations such as chrony, ntpd from
nwtime.org, and ntpsec already perform a "last day of month" sanity test.
OpenNTPD lacks such a test (that distribution doesn't implement leap
seconds at all.).
Such a sanity test reduces the probability that NTP propagates an incorrect
leap second warning.
Other potential protections were mentioned previously.

*Correct UTC*.  A leap second warning check inside NTP is not sufficient.
A bogus leap second procedure could still be executed within the GPS-UTC
adaptation layers.
Unless additional information is available (see Bob Camp's comments), NTP
trusts what the adaptation layer says and will deliver erroneous time to
its clients.

I observed over 150 NTP servers affected in November 2021.  I don't know
what will happen in October 2026.
Additionally, there may be non-NTP systems that are sensitive to UTC errors.

I'll start an email thread on the NTP email list, since that community is
more likely to be affected.

Steve