U.S. Moves to Kill Leap Seconds

blacklite001 writes "Not content with merely extending Daylight Savings Time, the U.S. government now also proposes to eliminate leap seconds, according to a Wall Street Journal story. Their proposal, 'made secretly to a United Nations body,' includes adding 'a "leap hour" every 500 to 600 years.' Hey, anyone remember the last bunch of people to mess with the calendar?"

More info

[interiot]

More info here [ucolick.org], with geeky charts and stuff.

over the past 30 years (coincidentally since the inception of leap seconds) the rotation of the earth's crust has accelerated. This acceleration is apparently due to changes of fluid circulation in the outer core of the earth. Historical investigations of earth rotation indicate that such accelerations are not unprecedented, and it should not be possible for the acceleration to continue for very many more years.

Apparently not...

[interactive_civilian]

According to TFA, it isn't working perfectly fine:

But adding these ad hoc "leap seconds" -- the last one was tacked on in 1998 -- can be a big hassle for computers operating with software programs that never allowed for a 61-second minute, leading to glitches when the extra second passes. "It's a huge deal," said John Yuzdepski, an executive at Symmetricom Inc., of San Jose, Calif., which makes ultraprecise clocks for telecommunications, space and military use.

On Jan. 1, 1996, the addition of a leap second made computers at Associated Press Radio crash and start broadcasting the wrong taped programs. In 1997, the Russian global positioning system, known as Glonass, was broken for 20 hours after a transmission to the country's satellites to add a leap second went awry. And in 2003, a leap-second bug made GPS receivers from Motorola Inc. briefly show customers the time as half past 62 o'clock.

"A lot of people encounter problems with their software going over a leap second," said Dennis D. McCarthy, who drafted the U.S. leap-second proposal while serving as the Navy's "Director of Time."

Now, I can't say that I completely understand why resetting a clock should be so complicated, but it seems to cause problems...

Big leap of faith...

[NetSettler]

Leap seconds and leap days aren't related. Leap days are related to the need to make a year's length expressible in integral number of days by a sort of infinite series approximation. Unless the length of a year were an actual integral number of days, leap days would be needed even if there was no "slowing" ever. By contrast, leap seconds are added to accomodate "slowing" and are not an artifact of the original relation. The use of the term "leap" for both of these is probably what attracts politicians to "leap" to the rescue. Perhaps they should take a second to reconsider...

I actually agree that leap seconds are a bit of a mess, and I wouldn't mind seeing a better solution. But the one proposed sounds a bit bizarre. Surely the real problem is an artifact of the infancy of computer systems and the ad hoc, non-general solutions to time representation we've been using due to very small address spaces that are rapidly falling by the wayside. Why not just delay the issuing of them for a couple of decades until we can think harder about the problem. Pretending that any law passed now is going to stand unused for hundreds of years before it has any effect seems a little ... arrogant. I'm pretty sure that, say, somewhere around 2027, we're going to have a lot of discussion about our present representation of time and whether it's the right one...

Re:The _last_ bunch?

[Wieland]

Also, IIRC, before the 1917 revolution the Russians were still using the Julian Calendar. The communists adopted the Gregorian calendar in 1918, which is why the so-called October Revolution was actually commemorated yearly on November the 7th.

Re:now correct me if im wrong

[Daverd]

Have they thought about redefining the length of a second

The second is one of the fundamental units in the metric system. Many other units and constants are based on the second. For example, the speedometer in your car shows miles per hour, the speed of light is given in meters per second, etc. If we changed the value of the second, then either:
a. We'd be forcing the world scientific community to relearn an entire set of new constants, or, more likely,
b. There would be two definitions of the 'second', the US definition and the scientific definition.

I don't think either of these is really what we want.

Re:neat bit

[imsabbel]

yeah, there IS a master atomic clock (or more like a cluster, with each clock weighted differently).
(also note that this ends 61, about the time atomic clocks became usable)

Re:Planet

[A beautiful mind]

This whole stuff reminds me of Xerxes [wikipedia.org] who ordered the punishment of the sea because the sea consumed his war fleet. When i mean punishment, i mean "whipping the sea". Makes sense if you're arrogant enough, i suppose.

Re:Hmm...

[TykeClone]

Powers granted to the Congress of the States:

Section 8, Clause 5: To coin Money, regulate the Value thereof, and of foreign Coin, and fix the Standard of Weights and Measures

Time is a measure, therefore they actually do thave the authority to regulate it.

Re:Really Good Reference on Time

[Teancum]

By far the best resource I've ever seen concerning time and navigation is: http://tycho.usno.navy.mil/ [navy.mil]

This has everything you mentioned above, plus some very current research, the role of the USNO in the GPS satellite constellation, and even the history of timekeeping in the USA. On the whole an excellent resource to look at if you want to know more about time.

Whenever I setup a new system, I usually drop by their "what time is it" to set the clocks on systems (especially if I don't want to download or enable a nettime client). It will get you the correct time +/- 30 seconds with the web interface, which is as good or better than most casual users really care to get it anyway. Usually far more accurate than most people's watches as well.

Re:Apparently not...

[cnettel]

Remember that a lot of systems use "seconds since certain point in time" (like January 1, 1970, GMT, you UNIX-based bastards). There are functions in the C runtime library to convert from those to normal calendar dates. I find it kind of unsatisfactory that you'll have to add in magic numbers for each of the leap seconds as they are added. Of course, having a leap hour for some coders in a few centuries won't be too nice, but they will probably be able to declare that it's coming several years in advance, or ditch it altogether. One way or another, I would like to keep the calendar definition and conversion between different types simple. Avoiding leap seconds is one tiny step along that road.

Re:Good question from a lazy asker...

[scruffy]

Unix time increases by 86400 each day, no matter whether there is a leap second or not. From the Wikipedia [wikipedia.org]:

When a leap second occurs, so that the UTC day is not exactly 86400 s long, a discontinuity occurs in the Unix time number. The Unix time number increases by exactly 86400 each day, regardless of how long the day is. When a leap second is deleted (which has never occurred, as of 2004), the Unix time number jumps up by 1 at the instant where the leap second was deleted from, which is the start of the next day. When a leap second is inserted (which occurred on average once every year and a half from 1972 to 1998; none at all have been or will be inserted after Dec 31, 1998 up through June 30, 2005), the Unix time number increases continuously during the leap second, during which time it is more than 86400 s since the start of the current day, and then jumps down by 1 at the end of the leap second, which is the start of the next day.

Re:Apparently not...

[42forty-two42]

It does, actually. At least in unix-like systems, time is represented by the number of seconds since January 1, 1970 (known as the Unix Epoch). There are C library functions to convert it to a date, accounting for time zone, locale, formatting, etc.

Re:Apparently not...

[makomk]

Apparently, Unix uses time since the epoch calculated *ignoring leap seconds*. Linux users - see time(2) manpage.

Re:I don't see how the problem occurs

[Sparr0]

therein lies the problem. i dont have a compiler handy, so all these numbers are made up (and obviously not correct or even scaled properly, but should at least be in the right order)... imagine second 100000 is 23:59:59 2006-12-31, 100001 is 00:00:00 2007-01-01, and so on. Then second 104729 would be 11:32:17 2007-02-14. but if a leap second is inserted at the end of 2006 then second 100001 will be 24:59:60 2006-12-31 and second 104729 will be 11:32:16 2007-02-14, and so on. this means an extra special case in the time functions, and a displayed time off by one second for people running old versions of the time libraries.

Re:now correct me if im wrong

[Erwos]

"The hebrew calendar works"

It doesn't actually work. It is slowly (VERY SLOWLY) but surely moving off, because the leap month isn't adjusting exactly how much it needs to. I was surprised when I heard this, too - but someone I know programmed one of the Hebrew calendars (it uses GPS coords to calculate exact sunset - quite nice), and showed me the math. Turns out things end up misaligning ala the Islamic calendar, but only after a very long time from now.

Now, the reason it _used_ to work is that the rabbinical court ("beis din") in Jerusalem would just not listen to witnesses about the sighting of the new moon until they felt like it - and if things were starting to get dicey, they'd just not hear it until the next day or something.

The Jewish calendar is lunar _based_. It is not actually a strict lunar calendar due to the human intervention possible in it. I don't think it's a great choice for system time-keeping.

-Erwos (who's a for-real Orthodox Jew)

Re:Apparently not...

[Phil Karn]

It actually does matter a lot in some applications. Take satellite tracking. A low earth orbit satellite moves about 7 km in one second. If you're off by one second because of confusion about a leap second, you've made a position error of 7 km. That's a lot.

There are many perfectly valid arguments against leap seconds. The difficulty in calculating the exact number of seconds between two events, the fact that calculations involving future times can give different results after leap seconds are declared, the difficulty of dating events that occur near or during leap seconds, all are serious drawbacks.

But these are not good arguments for removing leap seconds from UTC! Why do that when you can choose from two perfectly good standard time scales that don't have leap seconds? Those are the GPS (Global Positioning System) time scale and the TAI (International Atomic Time) timescale. They differ by a fixed offset: TAI is 19 seconds ahead of GPS and will remain so despite any future leap seconds added to UTC. (Strictly speaking the offset between TAI and GPS typically varies by some tens or hundreds of nanoseconds around 19 seconds, but the GPS system operators try to drive that error to zero, and they publish those offsets. The big advantage of GPS time, of course, is its ready availability from inexpensive receivers.)

CDMA digital cellular is one system that chose the GPS timescale to avoid the nasty discontinuities associated with UTC leap seconds. GPS times are still easily converted to UTC (or local time) for human consumption.

It would have been really nice had the UNIX designers chosen the TAI timescale instead of UTC as the internal representation of time. (GPS didn't exist back in the 1970s when UNIX was developed). Library routines could easily convert between TAI and UTC as needed for input and display, using configuration files updated every time a new leap second is declared, but you'd get a much cleaner internal representation of time. You wouldn't have the present situation where every timestamp for a past event is effectively moved one second every time there's a leap second.

I wonder if it's too late to make such a change...