[LEAPSECS] Longer horizon

[Michael Spacefalcon]

Daniel R. Tobias <dan at tobias.name> 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