If one reads about the Windows NTP client, it says that during the day the packets from the server (NTP - so it could be a Linux server) will indicate that a leap second should be done that day. But the Windows client ignores this. So, for a bit of time the client may be off by one second. But the next time sync corrects this and all is okay. Which implies that the server initially tells that a leap second is soon to happen. Then, at some point, the leap second is incorporated into the time. If my system prints the message that it did make the one second adjustment (it sets the current time back one second), the time must still get set correctly no matter if this adjustment was done. After all, it must work if my system is turned on after the second should have been added (the next day). Is this done this way so the client can choose to deal with the real leap second in some way other than the usual jitter? GPS receivers, on the other hand, do not incorporate leap seconds into their time. But they can indicate that a leap second should be added. I wonder if the information they provide is the cumulative number of leap seconds that should be added to convert GPS time into UTC time (currently 18 seconds). So, is it the case that ntp clients (ntpd, chrony), in order to set the local clock to UTC, should add leap seconds if the time source is a GPS receiver, and not add them if it is an NTP server? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org