The article title should include (1997) as the year it was written.<p>Much better (updated much more recently with the latest developments) link is:<p><a href="http://www.cl.cam.ac.uk/~mgk25/time/leap/" rel="nofollow">http://www.cl.cam.ac.uk/~mgk25/time/leap/</a><p>also<p><a href="http://www.ucolick.org/~sla/leapsecs/" rel="nofollow">http://www.ucolick.org/~sla/leapsecs/</a><p>"In 1970 the CCIR (predecessor of the ITU-R) decided to disconnect clocks from the rotation of the earth, but they kept the calendar connected to the rotation of the earth. That decision was implemented starting in 1972, and since then the leap seconds have maintained the connection.<p>In 2015 the ITU-R will decide whether the calendar will also become disconnected from the rotation of the earth. If the ITU-R decides to abandon leap seconds in UTC then the calendar day will become regulated purely by cesium atoms, not by sunrise, noon, sunset, nor midnight. The ITU-R will choose between these two options."<p>More background:<p><a href="http://www.ucolick.org/~sla/leapsecs/amsci.html" rel="nofollow">http://www.ucolick.org/~sla/leapsecs/amsci.html</a><p>The possible solution:<p>For most uses knowing about leap seconds is unnecessary. Ignoring them is convenient and enough for the common computers: you as the programmer can then assume that every day has 86400 seconds, and the variations due to leap seconds are probably less than those that happen due to your computer not having the atomic clock built in (the time provided by your hardware is, unsurprisingly, much less stable than the one of the atomic clocks and you probably don't care).<p>The most recent popular article by Kuhn (2015) explains the problem most of the programmers and computer users have is easily solvable without changing UTC:<p><a href="http://theconversation.com/an-extra-second-on-the-clock-why-moving-from-astronomic-to-atomic-time-is-a-tricky-business-35970" rel="nofollow">http://theconversation.com/an-extra-second-on-the-clock-why-...</a><p>"Unfortunately, the way NTP implemented leap seconds in Unix and Linux operating systems (which run most internet servers) made things worse: by leaping back in time to the beginning of the final second and repeating it. Any software reading off a clock twice within a second might find the deeply confusing situation of the second time-stamp predating the first. A combination of this and a particular bug in Linux caused computers to behave erratically and led to failures in some datacentres the last time a leap second was introduced in 2012, notably in one large airline booking system. Instead, alternative implementations now just slow down the computer’s clock briefly in the run up to a leap second to account for the difference."<p>And his proposal (since 2005, updated in 2011 based on the use of similar principle by Google, still valid):<p><a href="https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/" rel="nofollow">https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/</a><p>"UTC-SLS is a proposed standard for handling UTC leap seconds in computer protocols, operating-system APIs, and standard libraries. It aims to free the vast majority of software developers from even having to know about leap seconds and to minimize the risk of leap-second triggered system malfunction."<p>"Overall, the Google experience suggests that there is a justifiable need for a smoothed version of UTC for use in computer APIs, if only for due diligence reasons. (...) UTC-SLS has many additional advantages and remains a desirable and more robust candidate for a standardized, long-term solution for the same problem.<p>I like UTC-SLS as the best approach for most of common use cases.<p>Edit: now UTC-SLS can be also discussed here: <a href="https://news.ycombinator.com/item?id=9018504" rel="nofollow">https://news.ycombinator.com/item?id=9018504</a>