Slashdot Mirror
'Leap Seconds' May Be Eliminated From UTC
angry tapir writes "Sparking a fresh round of debate over an ongoing issue in time-keeping circles, the International Telecommunications Union is considering eliminating leap seconds from the time scale used by most computer systems, Coordinated Universal Time (UTC). Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases."
Perhaps Oracle should concentrate more on making their software reliable, and less on lawsuits.
From what I recall Digital VMS didn't have that problem, and even had no problems migrating an always on system over different processors, and keeping the cluster running over more than 15 years. One second and Oracle crashes.
It's a pity which of those companies survived.
Nobo has a point... but it would make it so that the hardware engineers would suffer instead of the software ones. 1/86,4000 of a day = 1 second could be a fair solution. All we would need to do then would be to come up with a new atomic clock which allows for the alteration and then come up with computer crystals that are accurate to the new system (hey, let's get ones that are accurate to begin with, that would be great).
But, since respectable companies tend to run their own SNTP servers and they themselves adjust against national servers (we hope), it could simply be a good idea to ditch the leap second in favor of fixing all the clocks.
But, I think the real issue of the article is the occasions where "17:59:60" is a valid time. I think for presentation (and databases), it would in fact have been better to simply prolong 17:59:59 or progressively added a millisecond for the next 1000 seconds for example. Although it might through off scientific calculations during that period, the impact would be less critical.
I've worked with NTP for nearly 20 years now, and the leap second adjustments isn't a real problem.
The crux of the matter is that we've insisted (in both Unix and Windows) on measuring calendar events in seconds:
The proper solution is to use Julian Day Number as the basic unit for calendars and (SI) seconds for any kind of short-term measurement. If you really need second/sub-second precision for long-term (multi-day) measurements, then you have to accept that the conversion is not just a matter of multiplying/dividing by 86400.
Calendar appointments and similar things should be defined by day number and some form of fractional day, not SI seconds.
NTP is somewhat to blame though: Even though it has full support for leap second handling (both adding and subtracting), the core of the protocol pretends that UTC seconds (without leap adjustments) is sufficient, i.e. NTP timestamps are defined to be in a 64-bit fixed-point format with 32 bits counting seconds since 1900-01-01 and 32 bit for the fractional seconds, i.e. sufficient to handle a 136-year block with a quarter of a ns resolution.
http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap
This causes small hiccups for an hour or so after each adjustment: The primary servers and those that either have a leap-second aware source or a cluefull operator keep in sync throughout the adjustment, while the remainder will slowly detect that their local clocks seems to be a full second off. Since this is way more than the default +/- 128 ms which NTP is willing to handle with gradual adjustments, NTPD will instead step the clock (backwards for an added leap second) and restart the protocol engine, after discarding all history.
Modern versions of NTP have been rewritten to use a vote between all otherwise good servers: If a majority claim that there will be a leap second at the end of the current day, then the local deamon will believe them, and thereby stay in sync even during the actual leap second itself.
Terje
"almost all programming can be viewed as an exercise in caching"
Do we actually care about that level of accuracy? The leap second is a stupid idea to start with. We have leap years because a calendar year is about a quarter of a day shorter than a solar day. Without them, you'd have the seasons slowly moving around the calendar. The equinox would move by one day every four years, and so on. This was a problem for pre-technical societies, which depended heavily on the calendar for planting crops and avoiding starving, but it's irrelevant now. We're stuck with it though, and it does make it a bit easier to remember where the seasons are, although they won't change by much over a person's lifetime.
Leap seconds, in contrast, are completely pointless. They exist because the SI day is slightly shorter than the solar day, by a tiny fraction of a second. This means that, after a few years, the sun will not quite be at its apex precisely at midday. How much is the variation? We've had 24 leap seconds since they were introduced in 1972, but a lot of these were to slowly correct the already-wrong time. In the last decade, we've had two. At that rate, it will take 300 years for the sun to be a minute off. It will take 18,000 years for it to be an hour off. These numbers are slightly wrong. The solar day becomes a bit under 2ms longer every hundred years, so we'd need leap seconds more often later.
In the short term, they introduce a lot of disruption (see air traffic control problems for a good reason why we shouldn't have them - safety-critical systems that depend on time synchronisation and don't reliably work with leap seconds. Great). They don't provide any noticeable benefit. Maybe after a thousand or so years, UTC time will be offset enough from the solar day that it will be irritating, but if people still care about the relationship between noon and midday then they can add a leap-minute or two to compensate. Or they can just let it drift. I'd like to think that a significant proportion of the human population will not be on the Earth by that point, and so purely local inconsistencies with the time won't matter to them.
I am TheRaven on Soylent News
It wasn't just Oracle. The Linux kernel would deadlock if the system was under load when the leap second happened. I only had one server hang, but a customer with a rack of busy servers had about half of them freeze. Lots of "fun" on New Year's Eve. Even more annoying was that the problem wasn't in handling the leap second, it was in printing a message that the leap second had been handled.