In message: <[EMAIL PROTECTED]> "Bill Hawkins" <[EMAIL PROTECTED]> writes: : My little program served the needs of civil time. It backs up : at 59 seconds because the display software can't handle 60. : That seems close enough for civil work. If you must have : monotonically increasing time then it is a mistake to use : civil time. You want TAI because you are not concerned with : time of day.
But the UTC standard mandates displaying 60 for the a positive leapsecond. Your program failed to implement the standard. Other program expect to have standard conforming time sequences. The stupid details matter and are important. Getting them right is hard because of the amount of research into the problem involved, the amount of time one has to spend testing all the weird edge cases, and the amount of time one has to spend proving to oversight boards that you did it right. There are also problems with just using TAI, as has been outlined several times. Time sources are in UTC, and you need a leapsecond count to recover TAI. Alternatively, you can push the problem into the time display code, but that means that 'naive math' to calculate a time is no longer possible and you have to have a table of all leap seconds to do the job properly. No matter which way you fall on this issue, you have problems that bite you when you least expect it. Your attempt to show us all how 'easy' it is ran afoul of these problems and rather proved our point. : As to not handling the leap second interval as 59, 60, 0, : what do you do when the Earth speeds up and it goes 59, 1? : If the variations are due to the mantle floating on the core, : there probably will come a time when it speeds up. You're not following the standard again. If the leap second is negative, the sequence is 57, 58, 0, 1. Again, it is all covered in the standard. Negative leap seconds, though extremely unlikely, are part of the specification, and also need to be tested. The sequence of time matters, and there is hardware that will fail if upstream time providers do it wrong. : As to manually setting a leap second switch with only 6 month's : notice, I don't understand your problem. I'd rather have a one : month notice so it didn't get postponed until the notice was : forgotten. I believe Mills' NTP has a leap second flag that : automates that part of the process. Yes and no. NTP only turns on the leap second flag on the last day of the year to say 'there will be a leap second today.' So while it automates much of this (and is the signal that the kernel uses to implement the leap second), it doesn't act as a good way to warn people that one is coming. That has to come through other channels. So while the computers are likely to get it right on the day of the event, if you've not made plans to ensure that other parts of your operation are covered, you'd be in for a surprise. I should also explain that I personally tested FreeBSD and ntp's response to a leap second. I've fixed bugs that were introduced shortly after the last leap second that had gone unnoticed for 4 years until I tested them. I've tested both the positive and negative leap second scenarios. I've found bugs in the kernel portion of ntpd as well. This stuff is hard to get right, even for experts like Dave Mills. Warner _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts