Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Earth Science

Leap Second Coming In June, 2012 142

Zoxed writes "IERS have just announced a leap second due at midnight, June 30th this year. Are your systems ready?" The last leap second added was at the end of 2008.
This discussion has been archived. No new comments can be posted.

Leap Second Coming In June, 2012

Comments Filter:
  • Mayans (Score:5, Funny)

    by Anonymous Coward on Thursday January 05, 2012 @09:56AM (#38596026)

    The *LAST* leap second occured in 2012

  • by alphatel ( 1450715 ) * on Thursday January 05, 2012 @09:58AM (#38596058)
    I demand at least 3^10x8 seconds advance warning.
  • I won't care (Score:4, Informative)

    by aglider ( 2435074 ) on Thursday January 05, 2012 @09:59AM (#38596094) Homepage

    I use NTP [wikipedia.org] on my systems!
    They fix the timers, I got mine fixed. Automagically!

    • NTP is great if you can get it for your platform, but I can't find a Turing tape of it anywhere for my mechanical watch!
      • I have yet to find a watch that doesnt drift a couple of seconds every year anyways

        So i am in the habit of simply resetting everything when i adjust for DST.

        I know this because i set one watch to GPS time and find it loses or gains a second every month. This has proven true countless times over the decade with hundreds of watches.

        • by ahecht ( 567934 )

          Casio Waveceptor FTW!

          http://amzn.com/B00134L9B6/ [amzn.com]

        • by dotancohen ( 1015143 ) on Thursday January 05, 2012 @01:47PM (#38600246) Homepage

          I have yet to find a watch that doesnt drift a couple of seconds every year anyways

          SLOW DOWN!

      • by Anonymous Coward on Thursday January 05, 2012 @10:52AM (#38597046)

        I found one here: Mechanical Watch NTP Client [wikipedia.org]

    • Re:I won't care (Score:5, Informative)

      by Soft ( 266615 ) on Thursday January 05, 2012 @10:17AM (#38596440)
      Not just NTP; the reference implementation. On the machines I checked last time around, those with the reference implementation handled time correctly; those with OpenNTPD just ignored the leap second and resynchronized later. I'll check again next summer, we'll see what happens.
      • > Not just NTP; the reference implementation.

        Or Chrony.

      • OpenNTPD (Score:5, Informative)

        by klapaucjusz ( 1167407 ) on Thursday January 05, 2012 @11:47AM (#38598176) Homepage

        OpenNTPD just ignored the leap second

        OpenNTPD has clearly been written by someone who doesn't understand NTP. For example, it advertises incorrect root delay and disperson [debian.org] values, which can cause clients to fail to achieve a majority vote, or to pick the wrong peer to synchronise against. (Earlier versions were even worse, they advertised themselves as being at stratum 0, which could cause synchronisation loops; this has thankfully been fixed, but it doesn't inspire much confidence in the authors' competence.)

        I've also found OpenNTP to fail to regulate the local clock on dodgy hardware (it would oscillate wildly, with an amplitude of 3 seconds or so), in situations where the reference ntpd coped just fine.

        Folks, do yourself and everyone a favour -- run the reference NTP [ntp.org], run chrony [tuxfamily.org], heck, run some SNTP client [icarus.com], but please avoid OpenNTPD.

        • Re:OpenNTPD (Score:4, Informative)

          by Anonymous Coward on Thursday January 05, 2012 @01:47PM (#38600236)

          I have written most of OpenNTPD. Besides a lot of other stuff.

          And to be honest, I am sick and tired of wasting energy on each and every unfounded accusation someone posts somewhere. So I won't go into detail.

          First of, portable or native OpenNTPD (native = the one that comes with OpenBSD)? That is a drastic difference, not just because the portable is ancient (if anyone cares, please maintain the portable, I'll happily put it up. And not just promises, I got a lot of them).

          Then, looking at ntpd alone doesn't cut it. OpenNTPD uses a different approach than most (all?) others, it leaves the timekeeping to the kernel where it belongs. And we adjusted the kernel subsystem for it on OpenBSD.

          and just one thing i want to pick out of the unfounded accusations:
          "I've also found OpenNTP to fail to regulate the local clock on dodgy hardware"
          that isn't OpenNTPD failing, that is your system's adjtime(2) failing.

          And now excuse me please, I prefer to spend my free time on writing code or with my friends.

          • Re:OpenNTPD (Score:5, Interesting)

            by klapaucjusz ( 1167407 ) on Thursday January 05, 2012 @02:58PM (#38601508) Homepage

            have written most of OpenNTPD.

            And you admit it?

            I am sick and tired of wasting energy on each and every unfounded accusation someone posts somewhere.

            Please show me where the OpenNTPD code computes the dispersion and root delay that it sends to clients, and I will retract my claim.

          • OpenNTPD was significantly more stable if I recompiled the kernel for pentium instead of 386. It was just a few milliseconds improvement in stability, but it was a clear difference. In the kernel config file there was simply a few consecutive lines labeled something like 386 486 586 686. I did nothing but commented out all but the 586 or 686 line and recompiled. This was about six years ago though, so I don't know if it's still an issue. I'm sorry I didn't subit a report back then. I meant to. Thanks for de

    • by mcavic ( 2007672 )
      1000 ms is a pretty big drift, so I assume NTP will have to step the clock and resynchronize. I'm not too worried about it, though. :)
      • by mcavic ( 2007672 )
        Actually, I believe WWVB has a leap second provision. I don't know if the NTP protocol does or not.
        • I don't know if the NTP protocol does [have a leap second provision].

          Yes it does -- that's what the LI (Leap Indicator) field is for.

      • It's provided for in the protocol and in the software. NTP (and Chrony) will simply insert an extra second.

  • if (($mon == 5) && ($mday==30)) {
       $sec = $sec + 1;
    } else {
       $sec = $sec;
    }
    • I think that would double every second for the entire day. Be more specific.

      • by Anonymous Coward

        Not only that, but this bug would kick in every year on June 30.

        Also... why the else clause? A good compiler will *probably*... no make that *hopefully* optimize that away...

        Christ that guy sucks!

        • by Tsingi ( 870990 )

          Not only that, but this bug would kick in every year on June 30.

          Also... why the else clause? A good compiler will *probably*... no make that *hopefully* optimize that away...

          Christ that guy sucks!

          I saw that too, then I thought, "It's Perl, do I really think that I know what it does?"

        • by Ossifer ( 703813 )

          Looks like May 30th to my human brain... Who's got the brain that came up with the idea of having months start at zero, but day of month start at one?!?!

          • Who's got the brain that came up with the idea of having months start at zero, but day of month start at one?!?!

            The same guy who decided that C arrays start at 0 instead of 1.

            One of the common, if not most common, use of the month number is to look up the month name in an array so the human used is told "June" instead of "5".

            Which reminds me of my wonderful Cruz book reader, running android, which has no ability to look up the month name from the number outside the full calendar app. When I set the alarm clock, the "repeat" shows, for my weekday alarm, "8:30 on 2,3,4,5,6".

        • Also... why the else clause? A good compiler will *probably*... no make that *hopefully* optimize that away...

          PHP is not compiled! But that code won't be run anyway, it is just taking up 21 bytes of RAM but no cycles.

    • by Myopic ( 18616 ) *

      $sec = $sec + (($mon==5) && ($mday = 30));

      • Ugh. You have reminded me why I left Perl behind for a language that has strict typing.

        sec += (mon == 5 && mday == 30 ? 1 : 0);

        • by Nikker ( 749551 )

          Ugh. You have reminded me why I left Perl behind for a language that has strict typing.

          sec += (mon == 5 && mday == 30 ? 1 : 0);

          umm you mean ?

          sec += ((mon == 5 && mday == 30 && hour ==0 && min == 0 && sec == 0 year == leapyear) ? 2 : 1);

          Still, that is pretty ugly but at least it works. Other wise time will only advance by 1 second every 4 years!

      • by gatkinso ( 15975 )

        And in 2013.... (and 2014, and 2015, and 2016....)?

        • by Myopic ( 18616 ) *

          Don't make the mistake of assuming this code runs forever in a loop.

          • by gatkinso ( 15975 )

            Well, it is going to have to run at least once a day in order to work.

            Which means once a day every year it is going to fuck up.

            • by Myopic ( 18616 ) *

              I accept your chiding, but don't let it rise to actual criticism. Humorous pedantry is one thing, but you don't have enough information for real pedantry. For instance, without seeing the whole program, you don't know whether the immediate previous line of code was

              if($year==2012) {

              You also don't know if this is code only run during May, June, July, August, and September of 2012, as a special process. So again, ha ha, I laugh with you for ways to make jokes about silly tidbits of code posted to an unimportan

      • Lost an equal sign there; your code is incrementing every day in month 5 (and also every year).
    • by gatkinso ( 15975 )

      Well, I think we now have a good example of how NOT to code.

  • Of course! My systems are second-to-none. You should see what it clocks in at - not exactly a minute set of figures! That's if you have the time..
  • by Vhaldera ( 1269312 ) on Thursday January 05, 2012 @10:08AM (#38596244)

    One small step for man; one leap second for computer systems?

  • by Clueless Moron ( 548336 ) on Thursday January 05, 2012 @10:11AM (#38596306)

    On 5, 10, 15 or 20 MHz: at 00:00Z you will hear minute consisting of 61 seconds.

    If you happen to have a radio controlled timepiece, this will also be your chance to see if they handle the leap second conversion or took the lazy way out and just rely on the next time sync fix the time.

    00:00UTC June 30th 2012 is a Saturday evening in North America. What better way to celebrate a Saturday night?

    • by SomeoneGotMyNick ( 200685 ) on Thursday January 05, 2012 @10:17AM (#38596442) Journal

      00:00UTC June 30th 2012 is a Saturday evening in North America. What better way to celebrate a Saturday night?

      Decisions, decisions....

      I was going to watch my grass grow instead, but your suggestion sounds more promising. It won't tie up the entire night for any other activities I may plan for that weekend.

      • Are you sure? June 30th is Saturday, so it should be a Friday night. Unless I am miscounting some leap day in between...
    • by Anonymous Coward

      On 5, 10, 15 or 20 MHz: at 00:00Z you will hear minute consisting of 61 seconds.

      If you happen to have a radio controlled timepiece, this will also be your chance to see if they handle the leap second conversion or took the lazy way out and just rely on the next time sync fix the time.

      00:00UTC June 30th 2012 is a Saturday evening in North America. What better way to celebrate a Saturday night?

      The sad part is, I really can't think of a better way to celebrate a Saturday night.

    • by Anonymous Coward

      Ain't no party like a leap second party, 'cause a leap second party... is really short.

    • I've listened to a couple of leap seconds on WWV. I've recorded them too. I think I need to get out more. They sound like tick...tick...tick...(silence 23:59:59)...(silence 23:59:60)...BEEP (00:00:00)...tick...tick...tick...

      ...laura

      • They sound like tick...tick...tick...(silence 23:59:59)...(silence 23:59:60)...BEEP (00:00:00)...tick...tick...tick...

        I'll leap right to the end of the cascade of Hellen Keller jokes::

        If a leap second fell on Hellen Keller, would she make a sound?

  • by ElVee ( 208723 ) <elvee61@gmai[ ]om ['l.c' in gap]> on Thursday January 05, 2012 @10:29AM (#38596644)

    Leap seconds are a tiny bit of problem when you have to time-stamp transactions coming in from all over the globe and keep them in date/time order. Some OSes don't support leap seconds, which complicates matters. We have the procedures documented from the last time this happened in 2008, but, of course, we've changed OS, DB and message queue vendors since then, so nothing applies anymore.

    Time to spin up a new project and pay some high-priced consultants a lot of money to rewrite the procedures documentation yet again. I suspect we'll take the coward's way out and shut down processing for a minute before until a minute after and resync the clocks in the interim.

    That will, of course, be charged to our SLA downtime, which will affect everyone's performance reviews at the end of the year. All this for a single goddamn second.

    • I suspect we'll take the coward's way out and shut down processing for a minute before until a minute after and resync the clocks in the interim.

      This was how I figured transaction processing would be handled. It sucks that you have to pay high-priced consultants to get that answer; plenty of people would give it to you for free.

      That will, of course, be charged to our SLA downtime

      I didn't consider this aspect. Thinking about it makes me realize just how stupid a leap second is. A lot of transaction processing requires >99.999% uptime, and even that two minutes (assuming everything goes perfectly smoothly) is expensive. Couldn't they be accumulated and have an extra leap year once every 86400 years?

      • by eh2o ( 471262 )

        Leap seconds are not stupid, basing a time scale on the rotation rate of an unstable object is stupid.

    • Some OSes don't support leap seconds, which complicates matters.

      Both unix and windows use time formats that assume there are 86400 seconds in a day. There may be papered on support for leap seconds but I wouldn't want to rely on it without extensive testing of the application/OS combination in question :(.

      • Both unix and windows use time formats that assume there are 86400 seconds in a day.

        Actually, both UNIX and Windows have two time formats:

        • the one that is more-or-less a count of second-or-sub-second intervals since a fixed time in the past;
        • the one that's year/month/day/hour/minute/second/maybe fractions of a second.

        Amusingly:

        • for the first of them, the UNIX one ("Seconds Since the Epoch" or time_t/struct timeval/struct timespec etc.) explicitly says, in effect, the clock freezes during positive leap seconds and jumps ahead extra fast during negative leap seconds, and the Windows one (F
        • Actually, both UNIX and Windows have two time formats:

                  the one that is more-or-less a count of second-or-sub-second intervals since a fixed time in the past;
                  the one that's year/month/day/hour/minute/second/maybe fractions of a second.

          They do but my understanding was that the former was the internal format while the latter was mostly for display.

          • Actually, both UNIX and Windows have two time formats:

            the one that is more-or-less a count of second-or-sub-second intervals since a fixed time in the past; the one that's year/month/day/hour/minute/second/maybe fractions of a second.

            They do but my understanding was that the former was the internal format while the latter was mostly for display.

            In most if not all UN*Xes, that's true. In modern Windows systems, it might be true, but I'm not sure; the fact that the "mostly for display" format is called SYSTEMTIME and the other format is called FILETIME, and that the call to get the former is GetSystemTime() and the call to get the latter is GetSystemTimeAsFileTime(), may or may not be significant, but they do at least seem to suggest that the "mostly for display" format is thought of as the Real System Time.

    • Afaict both windows and unix use core time formats that assume 86400 seconds in a day and simply cannot represent leap seconds. So even if leap second support is present in the OS it will be papered on and I wouldn't want to rely on it without extensive testing :(

    • ...That will, of course, be charged to our SLA downtime, which will affect everyone's performance reviews at the end of the year. All this for a single goddamn second.

      If you are concerned about your SLA, fix your software so it handles leap seconds correctly. You can test your fixes by hacking NTP to insert a positive or negative leap second at the end of every minute. When you get it working, you will have a competitive advantage over everyone who has to shut down.

  • by PPH ( 736903 ) on Thursday January 05, 2012 @10:34AM (#38596706)

    "Officer. The reason I was driving so fast is that I was trying to adjust my watch using relativistic time dilation."

  • by clickclickdrone ( 964164 ) on Thursday January 05, 2012 @10:44AM (#38596902)
    I need a lot more warning than this! We won't even be able to have the meeting in time to decide who to invite to the pre-project inception meeting.
  • Two days ago there were several articles stating that leap second might be abolished: http://www.scientificamerican.com/podcast/episode.cfm?id=leap-seconds-may-disappear-12-01-02 [scientificamerican.com] "This month the International Telecommunication Union will consider a proposal to abolish leap seconds."
  • Yes!! An extra second for drinking.

  • by Anonymous Coward

    Who is this "Leap"? Why is his second coming so important?

  • by Anonymous Coward

    Hey, did you think gettimeofday returned the number of seconds since the epoch? That a call to gettimeofday would return a value >= to the last call? Well, it doesn't, because it's based on UTC, which is defined as seconds since the epoch, minus leaps seconds.

    As a result, a value returned by gettimeofday does not refer 1:1 to a point in time, and the clock will skip a second backwards at random moments (leap seconds happen when IERS says so).

    I mean, you could put the leap second logic in the same place t

    • Hey, did you think gettimeofday returned the number of seconds since the epoch? That a call to gettimeofday would return a value >= to the last call? Well, it doesn't, because it's based on UTC,

      It's only "based on UTC" to the extent that the definition of "Seconds Since the Epoch" speaks of "Coordinated Universal Time name"; the formula to compute a "Seconds Since the Epoch" value from a "Coordinated Universal Time name", meaning year-month-day hour:minute:second expressed as a struct tm, can return the same value for two different Coordinated Universal Time names corresponding to different instants in time, so "Seconds Since the Epoch" is not actually a count of the number of seconds that have el

  • Is that ((leap second) coming) or (leap (second coming))?

    There's a significant difference!

  • It took me a few seconds to figure out the title. At first I thought we were supposed to jump for joy that Jesus was making a comeback in June. Oh I don't know...which is more exciting?

Your own mileage may vary.

Working...