Daniel R. Tobias <[email protected]> wrote: > Actually, from what I've seen and heard about this year's crop of > bugs, server crashes, etc., relating to the leap second, the big > problems come when the developers know and care just enough to be > dangerous.
Yup. > If you take the total dumbass approach to leap seconds, like you > don't even know they exist, or pretend they don't exist even though > you've heard of them, then in most cases your hardware and software > will muddle through just fine. It might wind up a second off after > the leap second happens, but that will just be an additional > one-second delta added (or subtracted) on to whatever other delta > might exist due to normal clock drift, which will eventually get > corrected (either in an abrupt jump or smoothed out, depending on the > system software) when the system next polls whatever external time > source it periodically syncs to (if it does this at all). That's exactly what happens on my current systems. > It's only when you actually attempt to get the system to account for > the leap second immediately and precisely when it happens that you > end up having to code in something convoluted that only runs every > couple of years, with all the potential to screw it up and cause a > major crash of some sort. Probably only less than 1/10 of 1 percent > of systems actually need this degree of precision, so the other 99.9% > are best off not even trying to do anything special for the leap > second, Finally, a voice of reason - that's exactly how I feel. Nice to hear that there is at least one other person who agrees with me, at least in this regard. > though some defensive programming to keep from crashing if > fed something like "23:59:60" from a remote site would be desirable. Of course. However, this issue would only exist if the external time input is an ASCII string or struct in HH:MM:SS format, and I have yet to see a system that uses such formats for time interchange. All systems that I'm familiar with use time-as-a-real-number formats instead: JD, MJD, time_t, NTP, etc. SF _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
