[ntp:questions] Leap second to be introduced in June

Martin Burnicki martin.burnicki at meinberg.de
Mon Jan 12 10:48:58 UTC 2015


Marco Marongiu wrote:
> On 12/01/15 06:10, William Unruh wrote:
>> I also admit I do not know how windows impliments leap
>> seconds.

The Windows operating system by itself is not aware of any leap seconds, 
as far as I know.

Due to this fact, I opened a bugzilla issue back in 2005
https://bugs.ntp.org/show_bug.cgi?id=508

At that time ntpd *only* passed the leap second warning to the OS kernel 
(and of course to NTP clients), but on OS types which didn't provide a 
kernel API which supports this ntpd just did nothing by itself to get 
the leap second handled properly by the OS.

Instead, it would detect a sudden 1 s offset after the leap second, and 
step the time back by 1 s about 15 s after the leap second, just as it 
does with normal time steps between 128 ms and the panic threshold 
(~1000 s). This also includes a flushing of ntpd's internal filters, as 
with a restart of ntpd.

Windows was just one of those OSs, but a very popular one with lots of 
installations running ntpd instead of w32time, so many NTP users would 
have to suffer from the time being off by 1 second for several minutes, 
and then be stepped *back* by 1 s.

You know, stepping the time back can very badly affect applications like 
data bases, etc.

As you can read in the comments to bug 508, especially comment 14, DLM 
anyway refused to support this in the stock NTP code:
https://bugs.ntp.org/show_bug.cgi?id=508#c14

> I don't have a reference, but I remember that at the time of the latest
> leap second I read that Windows will half the clock speed at 23:59:59 so
> that it reaches 00:00:00 at the right time. It pays the price of being
> wrong for two seconds in order to save the system from a discontinuity.

I'm also maintaining the driver software for Meinberg PCI cards, and 
when I opened bug 508 I already had some code which tried to work 
arround the missing leap second support in Windows (this means, AFAIK 
there is no API where a program can notify Windows that a leap second is 
approaching, so that windows can handle it by itself, like most *ix 
kernels do).

The workaround was indeed to slew down the system clock to half speed 
for 2 seconds, which means that after those 2 seconds the system time 
has only gained 1 second, and thus matches again the normal time after 
the leap second.

Since the system time always kept increasing over the correction there
were no bad affects for applications due to time being stepped back.

I ported my code to NTP and it was in some Windows-only section of the 
NTP code. However, it was hard to get this committed and a new NTP 
version be released, but it was already a month or so before the leap 
second event, so we at Meinberg decided to roll out an own version of 
NTP, based on the normal tar ball, but with a patch for leap second 
support in Windows.

We (Meinberg) made the code available at the beginning of December, 
2005, and called the version of the NTP installer for windows "Xmas 
Edition". ;-)
This was a variant of ntp-4.2.0b, see also:
http://bugs.ntp.org/show_bug.cgi?id=686

It still took some time until my patch made it into the official NTP 
sources, see also bug 686 mentioned above.


Some years after bug 508 DLM suddenly changed his opinion. He revised 
the common leap second code and implemented support for leap seconds on 
systems without appropriate kernel API, which would now simply step the 
system time back at the leap second event time. This was in the 
developer version 4.2.5, i.e. between the stable releases 4.2.4 and 4.2.6.

So at least it wouldn't take 15 minutes or so until the correction was 
made, and ntpd's filters weren't flushed, but this broke the 
Windows-specific leap second code I had submitted before.

At that time I was very busy and not closely looking at the evolution of 
the NTP code, but I became aware of this by a new comment to the old bug 
508:
https://bugs.ntp.org/show_bug.cgi?id=508#c25

Fortunately Dave Hart had some time to have a closer look at this, and 
fix it for 4.2.6, so unless something has been broken again in the mean 
time it should be fixed in 4.2.6 and later, and should work correctly.

I'm planning to do some testing soon to verify this.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list