Slashdot Mirror

← Back to Stories (view on slashdot.org)

Leap Second Coming In June, 2012

Posted by timothy on from the they're-calling-it-a-time-step dept.

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.

13 of 142 comments (clear)

  1. Mayans by Anonymous Coward · · Score: 5, Funny

    The *LAST* leap second occured in 2012

  2. I won't care by aglider · · Score: 4, Informative

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

    --
    Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
    1. Re:I won't care by Soft · · Score: 4, Informative

      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.

    2. Re:I won't care by Anonymous Coward · · Score: 5, Funny

      I found one here: Mechanical Watch NTP Client

  3. Re:has to corrects my code by Eraesr · · Score: 4, Funny

    php coders. pah.

  4. Listen to WWV in North America by Clueless+Moron · · Score: 4, Interesting

    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?

    1. Re:Listen to WWV in North America by SomeoneGotMyNick · · Score: 5, Funny

      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.

  5. It's a hassle, but a tiny one... by ElVee · · Score: 4, Interesting

    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.

    --
    - Pithy comment goes here.
  6. I work in a corporate environment by clickclickdrone · · Score: 5, Funny

    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.

    --
    I want a list of atrocities done in your name - Recoil
  7. Re:has to corrects my code by Average_Joe_Sixpack · · Score: 4, Funny

    That's because the perl interpreter sends each script to Larry Wall for review and correction.

  8. OpenNTPD by klapaucjusz · · Score: 4, Informative

    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 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, run chrony, heck, run some SNTP client, but please avoid OpenNTPD.

    1. Re:OpenNTPD by Anonymous Coward · · Score: 4, Informative

      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.

    2. Re:OpenNTPD by klapaucjusz · · Score: 4, Interesting

      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.