Slashdot Mirror


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?"

4 of 601 comments (clear)

  1. The connected geek question by astrashe · · Score: 4, Interesting

    The article talks about lots of problems that leap seconds cause with software.

    The problems don't come from the complexity of the underlying problem of adding leap seconds, but rather because leap seconds are added so infrequently that the code to handle the leap seconds isn't well tested.

    So the real question here (to me, at least) is this: what do the leap second problems tell us about how software is developed?

    Are people not thinking about leap seconds when they write code? Or are they thinking about them, but not testing the leap second cases properly? What's going on?

    And how does the emergence of really big collections of APIs affect this? I mean, if people use standard routines for calendar functions, and if people keep their tools up to date, shouldn't these problems be mitigated? Shouldn't we be able to have some hard core calendar geeks solve the problem once in the API, and carry the rest of us?

    If that doesn't work, why not?

    We can solve this particular problem by changing the calendar. But what if we couldn't, and we had to try to address it with engineering practices? How would we proceed?

  2. Re:Apparently not... by Entrope · · Score: 5, Interesting

    Resetting the clock is not complicated, but the current system means there is a 61st second in a minute, as your quote of TFA mentions. People -- including software developers -- are strongly used to dealing with 60-second minutes, and software sometimes makes that assumption. It just requires attention (sometimes a lot of attention) and extra code (sometimes a lot of extra code) to get it right, but since very few people pay attention when a leap second happens, bugs are easily overlooked.

    Since leap seconds are based on changes in the time period of Earth's rotation (the sidereal day), and the decay is both very slow and influenced by hard-to-predict factors, leap seconds are not reliably predictable. They can only be announced when they are necessary -- and so it is easy for the displayed time to drift if a leap second announcement is missed or ignored.

    Leap hours, though, are different beasts. Virtually every piece of software in the world that displays time knows how to deal with the hour jumping forward or backward. That transition happens predictably and affects a huge number of users, so errors are easily noted.

  3. Re:now correct me if im wrong by gstoddart · · Score: 4, Interesting
    The problem is that it isn't working fine. To begin with we should have 13 months in the year, not 12. Months are supposed to reflect lunar cycles and there are 13 of them a year.

    Actually, the 12 months was to align with the constellations of the zodiac so that certain constellations will be in the same place at the same time. It keeps astronomical calendars in tune.

    Cultures which slavishly kept to a lunar calendar (another method of timekeeping, but it ignores the fact that we revolve around the sun) found that every bunch of years their months would be in the wrong season.

    A month is an abstraction made by humans for timekeeping, there is no 'should have 13 months' that closely aligns with actual astronomical time passage, which is far more important.

    Keeping track of solstices and equinoxes are really important when it comes to things like knowing when your seasons are changing.
    --
    Lost at C:>. Found at C.
  4. Re:Apparently not... by sallen · · Score: 4, Interesting
    That won't work in applications where countrywide synchonization with a precision in fractions of seconds is needed, such as some same-frequency-broadcasts or GSM networks. On the other hand, those probably already have real solutions for this problem, instead of a kludge.


    Bingo. You mean synchronization with precision like that which has been used for decades by the telco's (read: ITU jourisdiction). This is a problem what isn't one. Time is relative (sorry, couldn't resist.) I can't believe anyone, let alone Naval Observatory dude thinks in terms of sync to, essentially, a wall clock. That's why internal clocks are used. The time representation for someone looking at the 24 hr clock is simply a representation of an internal clock converted to something us dumb humans can relate to. Is this guy an idiot or what? If he'd been around many years ago, there wouldn't be binary systems, we'd all have to be on decimal systems, becuase he probably couldn't count either (That'll be his next recommendation.) And what happens when they try and add the 'leap hour'? I'm sure he looks at it like the deficit... he won't be around when it has to be taken into consideration. But I guarantee it'd make the millenium 'bug' (ie, original laziness) look like a cakewalk.
    As for 'nobody uses a sextant' since we have good old GPS, tell that to the sailors not too many years ago who lost all nav equip and used hmm... a sextant. One NEVER abandons the ability to utilize alternate means of problem resolution. He figures there's no possibility GPS could ever fail or be subverted? Bad mistake. That's what kills people, not leap seconds. He'd probably be the one to say take INS out of planes since GPS works. Right. I'll never fly over the ocean if he's that ignorant.