'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."

Comments

Hmmm

[HappyClown]

Now waaaaaait just one second! Oh, scratch that...

Poor solution

[LostMyBeaver]

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.

Re:Poor solution

[LostMyBeaver]

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.

Re:Poor solution

[Thorsett]

Why adjust for solar time?

We adjust for solar time because UTC is an astronomical timescale, not a "count of seconds since a specific time." If "computer people" want a timescale that ignores leap seconds, they can use an atomic timescale like TAI (or GPS time, which is a constant offset from TAI). But choosing to standardize the internet on UTC and then complaining it is too hard to do the programming right is a little like buying a house next door to a turkey farm and complaining about the smell.

Oracle

[Anonymous Coward]

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.

The problem with leap seconds...

[NixieBunny]

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.

Re:The problem with leap seconds...

[joe_frisch]

We could fix this tricky programming issue by regularly adjusting the earth's orbit....

Re:Oracle sholuld simply fix their software...

[nacturation]

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.

Changing time because of Oracle?

[koinu]

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.

Re:Stupid

[tagno25]

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 root of the problem

[Joosy]

The original article has a quote from one person who sees through the mess to the root of the problem:

The revision "doesn't resolve the underlying geophysical issue"

Simply resolve the "underlying geophysical issue" and the problem will be solved.

Ok...

[Chyeld]

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?

The real problem is using seconds for everything

[Terje Mathisen]

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

Let's see if I've got this right

[Joce640k]

We have to make every clock in the world inaccurate because Oracle's software is crap...?

Re:Let's see if I've got this right

[TheRaven64]

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.

Re:Let's see if I've got this right

[stdarg]

Eh, let a future generation fix Oracle's code.

Re:Let's see if I've got this right

[Burdell]

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.

Re:Let's see if I've got this right

[Kjella]

Daylight Savings has had numerous studies showing reduced electricity consumption.

Yes, the question is more if there's more or less hassle to have summer and winter opening hours than to change "time" itself.

Re:Let's see if I've got this right

[AltairDusk]

Flight industry and safety equipment also goes through very stringent testing. If the capability to handle leap seconds isn't included in their battery of tests then they have a hole in their testing procedure.

Re:Let's see if I've got this right

[TheRaven64]

No it can't, for three reasons. Firstly, leap days are deterministic. They happen based on a set of simple rules. If the year is divisible by 4, you get a leap year, unless the year is divisible by 100 but not by 400. Leap seconds, in contrast depend on a variable that changes daily, so are not predictable. They are fudged in with a few months notice, requiring every computer that needs to deal with them to be updated regularly.

Secondly, leap years don't violate basic sanity checking rules. You can assert that every month is 28-31 days, and that's not broken by leap years. You can assert that every minute contains 60 seconds. In the last decade, that has been true for 2,106,718 minutes, and false for 2. In every year before 1970, it was true.

Finally, leap years solve a real problem. The point of a solar calendar is that the seasons are in the same place every years. Having the seasons move made it difficult for people to plan when to plant crops. It's less important now, but having the seasons move around would be noticeable for everyone and irritating for a lot of people. In contrast, the only 'problem' that leap seconds solve is that the sun is not at its highest above the meridian at precisely 12:00. As the poster above you pointed out, the skew from not having leap seconds for a thousand years makes less of a difference to the position of the sun than simply not living quite on the meridian.

Leap seconds are a (very) complex solution looking for a problem.

Re:Let's see if I've got this right

[cizoozic]

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.

Well in that case it's probably easier for Oracle to just buy the Sun.

Re:Let's see if I've got this right

[Rockoon]

..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.

Re:Stupid

[bickerdyke]

Why abolish it?

You're free to CHOOSE your timescale! GPS, UTC, UT1, TIA.....

So if leap seconds confuse you, use a timescale without them. Thats what they're for. But keep the timescale that's supposed to be in sync with earth rotation in sync with earth rotation!

Quite obvious

[kthreadd]

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.