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."
They aren't predictable in advance. They are basically the noise in the solar system's timekeeping. It's impossible to write code that knows in advance when they will occur, since they are only announced six months ahead of time. So any clock that wants to stay in sync with UTC must be connected to either NTP or GPS or similar timekeeping service.
If only those darn astronomers didn't care so much about keeping the sun at Greenwich precisely at the meridian at high noon, we wouldn't have this problem.
The determined Real Programmer can write Fortran programs in any language.
Isn't the problem with Oracle here? It should not be that difficult to fix their software. What's the difference with Summer time change?
The difference with spring/fall time changes is that although the local time may change, the UTC time does not. In other words, your offset from UTC (eg: GMT-8) may get adjusted depending on your location's observance of daylight savings time but UTC itself simply marches on oblivious to anything. The leap second is the one exception.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Yeah, leap seconds suck, but the proposed solution (to let UTC drift farther and farther away from reality) sucks even harder. UTC should just be abolished in favor of UT1. Computer clocks are so crude anyway (mine is off by 3 seconds right now) that the supposed benefits of UTC's constant second are really non-existent, every computer needs to have its time adjusted now and then no matter what.
And that is what NTP is for. To automatically adjust the computers clock to account for drift.
The historical record of time_t is already ambiguous and cannot be corrected by abandoning leap seconds. There is a way to get leap seconds out of the kernel and into user space which amounts to reclassifying them as decrees of change of civil time and putting them into zoneinfo while letting the broadcast time scale not have leaps. It's a matter for posterity whether the word "day" will be re-defined by the ITU-R, changed from the current treaty-specified "mean solar day" to a technically-defined "atomic day".
Well, if you tell your NTP client to use those ten servers for setting the time chances are your computer's clock will be very accurate.
Greylisting is to SMTP as NAT is to IPv4
You'd get very confused - there was no 0 AD (or BC for that matter).
1 BC was followed by 1 AD.
Well if you want to get technical it was neither.
I think it was called 753 AUC
1 BC was followed by 1 AD.
Not with ISO 8601 time representation, which is more logical having a year zero before year one.
There's a reason why the second is defined based on an atomic phenomenon. An earth day is something hilariously unreliable; it varies all the time. A near earth asteroid would measurably alter it. Today we can measure time with accuracies in the 10^-15 or something, possibly even less. And besides, you're confusing the problem of defining the base unit (second) with choosing its scale and keeping a calendar. The SI second was scaled to look like the standard second used for centuries, just defined more precisely. The problem here is that the "real" second in the historical definition (one nth of a day) varies because of astronomical phenomenons that cannot be predicted (unless you can solve the n body problem for n very large and have inventoried the whole solar system), it's not a time keeping problem.
There's a solution to all this, it's called TAI. There is no reason not to use it but ignorance and incompetence. Every other "solution" that has been advanced here was completely, utterly stupid.
Oracle is just being used as an example in the summary. They are not the only people to develop software that doesn't properly work with leap seconds. Check the Slashdot archives, and you'll see a story about how a lot of air traffic control software doesn't either. ATC software is safety critical - if it goes wrong, planes can crash - and it depends heavily on synchronising clocks with a variety of different places. And these are just the examples that people have already found - how much other code do you think has been tested against an event one second long that's only happened twice in the last decade?
I am TheRaven on Soylent News
I think it was called 753 AUC
According to Wikipedia, it tended only to be called that by later historians:
Renaissance editors sometimes added AUC to Roman manuscripts they published, giving the false impression that the Romans usually numbered their years using the AUC system. In fact, modern historians use AUC much more frequently than the Romans themselves did. The dominant method of identifying Roman years in Roman times was to name the two consuls who held office that year. The regnal year of the emperor was also used to identify years, especially in the Byzantine Empire after 537 when Justinian required its use.
The first two things that came to mind were the Indiana DST changeover and the Australia study. Then I found this nice Wall Street Journal article that mentions both: http://online.wsj.com/article/NA_WSJ_PUB:SB120406767043794825.html
On the other hand, modern studies such as:
http://energy.ca.gov/2007publications/CEC-200-2007-004/CEC-200-2007-004.PDF
and
http://online.wsj.com/public/article/SB120406767043794825.html
(don't have a link to the article they published, sorry)
These imply that the savings are negligible or, in the case of Indiana, *increased* electric usage. There is no clear answer, since the results depend heavily on the breakdown of electric usage (A/C, eletronics, etc), which varies depending on your region.
..or its actually difficult to 'handle' leap seconds. I can tell that you've never worked seriously with time values as a programmer.
If you can't answer "When will each of the next 10 leap seconds be?" and "When were the last 10 leap seconds?" then you are pretty much fucked from a programming standpoint of 'handling' it in any sane manner using common time encodings, which use a count of intervals (usually seconds, or milliseconds) since some specific date and time.
Leap seconds make it impossible to incorporate them into intervals because leap seconds are not computationally predictable.
They are simply arbitrary announcements from the time keepers "we are adjusting the clocks by 1 second on such and such a date. We dont know when we will adjust them again.. we'll keep you posted."
Leap seconds are not like leap years, which are easily handled because they are introduced systematically based on only the interval value.
"His name was James Damore."