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."
Now waaaaaait just one second! Oh, scratch that...
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.
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 proper solution is to make programmers aware of leap seconds. There are 86400 seconds in a normal day, however there is an additional second added once or twice a year to adjust for solar time.
Wikipedia documents it quite well and programmers in modern times should be heading to wikipedia almost constantly anyway. The real problem occurs when the date/time is given in seconds since an "event" such as Jan 1, 1970. Most programmers don't know about leap seconds and I must admit, I don't generally bother calculating for them. But if it were necessary, it would be relatively trivial to do so.
We shouldn't remove fixes to the clock just because programmers are undereducated. I'm quite convinced that just posting this on Slashdot will raise awareness across a high percentage of the programming world.
I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it. Last formal education I had on time (not talking about physic related, but calendar) was in primary school. There are so many time systems out there that we should pay more attention to educating programmers on it.
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.
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.
Leap seconds are handled well, when the system supports it well and the software is not utter crap.
I am always annoyed when people break basic things to make software work (e.g. hardware, also see ACPI). Now they are not only breaking hardware, but redefining measurements to make buggy software work. What comes next?
I can understand when something is changed for convenience purposes (to have simpler calculations), but justified with buggy software is plain wrong. And I surely don't care if an Oracle database "reboots"... whatever that might mean.
The original article has a quote from one person who sees through the mess to the root of the problem:
Simply resolve the "underlying geophysical issue" and the problem will be solved.
I'm sick and tired of these hip, "ironic" sigs. This is an actual, honest-to-goodness no-nonsense sig!
Isn't this like legislating that PI is 3.14 because some people have problems with the idea of irrational numbers? If programs have issues with leap seconds, it sounds like programs weren't written properly, not that the spec needs to be rewritten to accommodate this flaw. Would these same people have demanded that it be 1999 again to avoid all the costs of the Y2K fixes?
Sounds to me like some programmers are putting the blame on anyone else than themselves ... I'm wondering, how do computer systems cope with re-syncing the local clock with a remote time source, e.g. NTP server? Computer RTCs are _never_ exact, so updating the local time is necessary in regular intervals, which will always lead to time jumps of milli-, micro- or even complete seconds and more. If your software can't cope with that, fix your software, but don't expect the universe will adapt to fix your shortcomings!
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".
I think it makes absolutely no sense for most computers or programmers to have to account for leap seconds.
The reality is that computers already have to allow for their clock drifting from universal time, that's why we have NTP. There's no point getting individual computers account for leap seconds, it would be easier and less error prone if reference clocks transparently accomodate leap seconds (ie without sending a 23:59:60 to the world) and everyone else can just drift back in sync with them when one occurs.
There may be a few applications where a computer really does need to accomodate leap seconds (such as a reference clock!) but for the rest of us the additional complexity gives no advantage whatsoever.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
So you knew that leap seconds should be tested for, did you?
I'm not defending Oracle, but at least give them this much credit - leap seconds don't exactly spring to mind when you're planning a test suite for software. Certainly after this incident I can't imagine they would miss it again, but I'd have been surprised if anyone can claim they knew to test for these beforehand.
Man who leaps off cliff jumps to conclusion.
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"
We have to make every clock in the world inaccurate because Oracle's software is crap...?
No sig today...
Every day is a slightly different length due to tides, etc. Even strong winds can shave off (or add) a microsecond or two.
The BBC did a documentary on it.
No sig today...
Accounting for leap seconds is complicated and error prone. It's also completely useless; the solution exists and it's called TAI.
Example: how do you figure how long an operation has taken? With TAI: := tai() := tai() - starttime
starttime
dosomething()
duration
That's it. How do you do that with leap seconds sneaking on you? It's impossible to do, at least reliably.
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.
Clocks should strive to give the most accurate measurement, not lie to their users.
The solution exists, it's TAI. You use TAI internally and convert to UTC (or your TZ) when displaying, similar to unix time.
This is one of many, many attempts to make the problem seem to go away, unfortunately enough their choice of 1000 seconds for the smoothing period is close to the worst possible: 1 second in 1000 is 1000 parts per million or 1000 ppm.
NTP has a maximum slewing rate of 500 ppm or half a second every 1000 seconds, so if your NTP upstream server was to start such an adjustment period, every single connected client would drop out of sync and be forced to do several steps each time the offset got above 128 ms. :-(
To make this work every single computer clock would need to be updated, while all the national radio standards, like the German 77,5 MHz transmitter, would have to disregard the new standard because the radio receivers would be unable to track it when it started the adjustment period.
Terje
"almost all programming can be viewed as an exercise in caching"
Well obviously the Oracle software worked properly and noticed that the customer had not payed their license to include the extra unlicensed second of operation.
No, they don't. For many low end computers, the clock chip is quite inexpensive, and they're under pretty harsh thermal conditions (dependent on layout, airflow, and heat from the CPU or other energy devouring components. The quartz crystal on your wrist doesn't experience anything like those thermal variations: this is why most computers are expected to synchronize with a master clock, such as an NTP service.
I'll second that. Make sure the minutes reflect that.
rewriting history since 2109
The solution, as the parent says, is to continue publishing leap second announcements but to start distributing TAI. Those who feel a need to track UTC can then insert the leap seconds themselves while other can track TAI and provide lookup tables for conversion to UTC or local time for display just as we do now for DST an local time zones.
And no, this does not mean putting the correction off for some future generation to deal with. It means realizing that there is no need for a correction at all and that Earth rotation based time is merely a local convention to be handled by an appropriate lookup table.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
why don't they drop the silly daylight saving time thing.
Its been proved that nowdays it doesn't save any electricity, and just messes up peoples schedules and biological clocks.
In the latest issue of SciAm its listed and one of the inventions humanity would be better off without. (along with the space shuttle)
The problem is that it would introduce variable seconds, which would cause much worse problems.
One example is electric power systems. The frequency in the AC power system is what determines how much power should be generated, if the frequency is above or below 60 Hz (or 50 Hz) then each power station should decrease or increase their generation by some amount proportional to the frequency difference.
The accumulated difference in total cycles over a period is used to calculate what was the difference between total energy needed and generated on that period. With leap seconds all you need to do is to divide total cycles by total seconds to get average frequency. With slow adjustment this would be much more difficult.
Oh, it's definitely no hassle as long as the correct measures are taken.
First, you need to make sure that you standardize the summer and winter hours across the whole nation, so that everybody switches over on the same date. It would be very confusing to have to call every business you deal with in order to ask whether they've already switched over to winter time.
Second, you should probably amend all local laws that specify specific times of the day so that they specify different times for summer and winter. You know, if my neighborhood bar opens at 8pm in summer and 7pm in winter, I would be pissed if a law that forces bars to close at 2am went unamended. I'd get one fewer bar hour in summer, and that's clearly unacceptable.
Third, in addition to amending all the laws, you have to make sure that you redo all the street signs that mention specific hours, so that that "free parking after 6pm" sign now lists separate summer and winter hours.
Fourth, whenever you schedule a late or early appointment in your calendar at a significant time ahead, make sure you take care to check whether the day you're scheduling it for is not past the switchover date, and you accidentally schedule the appointment for a non-laborable time for that season. Hey, we should probably redesign paper agendas so that the lines showing the working hours change for the seasons.
So you see, yes, it's definitely no hassle at all, as long as you take all of these measures, and any other ones that I may have forgotten.
Are you adequate?