Steve Summit wrote: > Tony Finch wrote: >> Even though NTP can represent current UTC correctly, it often gets leap >> seconds wrong. It does not give confidence that we will be able to >> reduce bugs by teaching more code about leap seconds, when NTP cares >> about time and gets it wrong, and most code cares much less. > > I feel a little bit like I'm rearranging deck chairs on the > Titanic with this kind of suggestion (and I know this isn't the > NTP list), but the appalling number of NTP servers that got it > wrong this time around made me think that another extension NTP > needs is a way to announce an upcoming leap second (i.e. one it > knows about) more than 24 hours in advance, so that those of us > who care can confirm that the servers we're using are going to > get it right.
I don't believe this is necessary. If the existing ways to announce a leap second are used correctly then ntpd gets it right, in that it notices the kernel of the upcoming leap second, and also forwards the announcement out to its clients. However, as mentioned in my other post, if the information passed to ntpd is not correct then it can't act correctly. If you introduce another extension to provide leap second information then this even becomes more confusing: what if the extension field announces a leap second, and the upstream server(s) / refclock(s) / leap second file doesn't? Or any variation of the above? If you provide your NTP daemon with a *current* leap second file then your ntpd knows about 6 months in advance if a leap second has been scheduled, and it also knows the TAI offset it can pass down to the kernel. There is the new tzdist protocol which could be used to update the leap second table automatically, and there is a proposal by Poul-Henning Kamp how this could be done via specific DNS queries: http://phk.freebsd.dk/time/20151122.html Martin _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs