Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re^3: Leap second coming up. Check your date handling code (practical)

by tye (Sage)
on Dec 28, 2016 at 05:36 UTC ( [id://1178552] : note . print w/replies, xml ) Need Help??

in reply to Re^2: Leap second coming up. Check your date handling code (reality)
in thread Leap second coming up. Check your date handling code

Well, if you do your duration calculations in that manner, then you are going to have to deal with getting a different answer depending on when you do the calculation (and when you upgrade the list of leap seconds).

I recommend not doing duration calculations in a manner that tries to account for leap seconds as I find a duration being slightly "off" (from some perspectives that might not actually apply to your system) when it crosses the year boundary of certain rare years to be better than having answers change. Similarly, I also prefer having epoch seconds progress very smoothly rather than having them stutter around a leap second (unless I'm doing some pretty unusual types of processing that likely wouldn't be done based on some Unix/Windows system real-time clock anyway).

I routinely see time measurements being off by much more than 1 second simply because hardware clocks are reasonably variable and NTP infrastructure is very often not given so much attention that it is kept operating so well that clocks are always kept within less than 1 second of true.

In fact, I recommend doing duration calculations not using real-time clock data at all, if possible. It is usually much better to do duration calculations based on a high-resolution monotonic clock (but such isn't always possible).

Now, if you are programming an atomic clock or a GPS system, then you certainly need to account for leap seconds, but you won't be using DateTime either. Now, you might be using DateTime to process high-resolution UTC times logged from some external high-precision clock such as for some astronomy work. In such a case, you want to make sure you have knowledge of new leap seconds in place before those leap seconds happen and then need that data processed, of course.

But warning people about keeping their Perl infrastructure updated because a new leap second is coming in such a general manner is most likely to lead to more confusion than enlightenment for most people -- who both don't understand the practical impact of leap seconds well and don't realize that they pretty much don't matter for any of their work anyway. In the tons of date/time-handling code that I've worked with over about the last decade, none of it is impacted at all by leap seconds (because I'm not working on astronomy software that deals with high-resolution external clocks that output real-time values).

Though, I work with tons of systems that claim to be using UTC. This can partly be blamed on fashion and such systems should likely be switched to GMT so that they stop lying about the types of real-time values they are working with. Until you've made such a switch, then accounting for leap seconds is more likely to cause problems than to improve accuracy (and once you've made that switch, the leap seconds won't matter).

- tye        

  • Comment on Re^3: Leap second coming up. Check your date handling code (practical)