Leap Second May Be On the Chopping Block (ieee.org)

szotz writes: The days of 61-second minutes may be coming to an end. The World Radiocommunication Conference is meeting for nearly the entire month of November, and one of the hot-button issues is what to do about the leap second. The addition to UTC is supposed to keep atomic time aligned with Earth's rotation, but past leap seconds have caused server crashes, and some are worried that future problems could be even worse. Going into the conference, it doesn't look like there's much of a consensus on what to do. One official is expecting weeks of debate.

Comments

It's not the Earth's fault

[plover]

So people write crappy code and rely on it without adequate fault tolerance strategies and that's somehow the problem of people who measure time? I think not.

Re:It's not the Earth's fault

[Anonymous Coward]

There will certainly be lots of problems if and when software is required to cope with relativity of time.

But, whenever that does happen, it is certain there will be people complaining the old code is crappy because it does not take the necessary details into account.

Re: It's not the Earth's fault

[aaron4801]

One second is "the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom."
Everything else is derived off of that. Why does one minute every few years have to be redefined just to keep "one day" relatively constant? They've effectively got two units of measurement that conflict with one another. We let "one year" drift enough that it only needs to be corrected once it's off by a whole day. Why not let those seconds accumulate and have a second leap day every hundred thousand years or so?

I'm majorly confused

[holophrastic]

In my 35 years, I've always seen time as a counted measure of how much time has passed since I started counting. I seem to be forever learning that's my novel idea.

Why should I care where the sun is, where the moon is, where the earth is, with respect to time? If it's winter, I can start work at 9, I can start at 10, I can start an hour after sunrise. I don't need to adjust my clock to start work at the same clock-display every day. I see nothing wrong with a company that has different business-hours by the season.

Similarly, since I'm not in the old west, I don't care if "high noon" is an noon, or 1, or 1 second after noon. I've never determined the time based on the sun.

Last I checked, we have perfectly wonderful time-keeping and gps devices these days. So ocean ships and submarines no longer need a sextant and a chronometer to figure out when and where they are.

So here's my petition. I'd like time to always move forward, and the same rate of 1 second per second. I'd like it to not jump, leap, crawl, rewind, fast forward, restart, end , or eject.

Shit, I just realized that I'm not 35 years old. Or I am 35 years old, but not when measured in seconds. Wait for it...ok, now I'm 35 years old. Phew.

there is only one viable solution

[Anonymous Coward]

Naturally: the earth's rotation must be sped back up to match the clocks.

This avoids any trouble with legacy systems crashing and so forth, and is likely easier to implement.

If you can't deal, don't use UTC

[oneiros27]

There are plenty of systems for time that *don't* involve leap seconds.

If your system's too crappy to be able to deal with leap seconds or you don't have a way to update them, use TAI or GPS time.

Don't screw with the definition of UTC just because you can't handle the complexities of it. It's not like someone's forcing you to use UTC, UT1R, or one of the other UT systems that are specifically intended to deal with issues of local noon.

(disclaimer: I work for a group that deals with solar observations*)

* and even one of them almost screwed the pooch and didn't distribute the update for the June/July 2015 leap second until 3 days before it happened ... and of course it was compiled in (for speed, they claimed**) rather than be an external file.

** if it really was for speed, then they need to flip their giant if/then structure so it starts in the present and walks backwards in time, rather than how they're doing it now where it runs dozens of tests that will always fail for a spacecraft that wasn't launched 'til 2010.

Leap-Seconds Existed More Than 45 Years Ago

[DERoss]

Leap-seconds were properly handled in computer software before most of today's software engineers and programmers were born.

Back in 1969, I started working on a software system that already handled leap-seconds quite smoothly. At that time, keeping UTC aligned with the rotation of the earth involved introducing fractional seconds and also having UTC seconds NOT the same duration as atomic seconds (TAI). In 1972, this was simplified by having UTC seconds exactly the same duration as TAI seconds and (after an initial fractional leap) introducing only leaps that were full seconds. The software in the system on which I was working DID NOT HAVE TO CHANGE!!.

Internally, the system on which I was working -- which evolved and continued in use to operate military space satellites for over 20 years -- kept all time in TAI, which never has leap-seconds. A relatively small routine converted in either direction between UTC for displays and TAI for internal time. Another small routine converted from UTC to UT! to sidereal time, the latter more closely reflecting the rotation of the earth, which is gradually slowing and also has predictable periodic fluctuations. The purpose of all this was that we needed to know very accurately the spot on the rotating earth directly under the orbiting space satellite. The position of the satellite was known in TAI while the surface of the earth was rotating very closely to sidereal time.

Also note that the network time protocol (NTP) also accounts for leap-seconds and has done so for decades.

I can only conclude that the current attempt to do away with leap-seconds is a result of lazy software "professionals" trying to shift blame for their ignorance about leap-seconds.