OpenBSD Journal

Handling Leap Seconds the OpenBSD Way

Contributed by pitrh on from the bounded leaps dept.

Christian Weisberger (naddy@) let us all know what we need to do to prepare for the impending leap second:

As you may have heard, a leap second will be upon us at 23:59:60
UTC on June 30.

The sky will fall, civilization will end, and dinosaurs will roam
the earth again.  Well, maybe not.

Neither the OpenBSD kernel nor OpenNTPD handle leap seconds in any
way.  So what will happen?
After the leap second, your OpenBSD system's time will be off by,
well, one second.  Gasp, shock.  Let's say you synchronize your
clock with ntpd against a server that does have the correct time.
At the next poll, i.e. within about half an hour, ntpd will notice
the offset and correct it, which will take a few minutes.  That's
it.  (I expect ntpd will drop down to a short poll interval and the
frequency correction will fishtail a bit since it's a differentiator
reacting to a jump.)

Unless you obsessively watch your ntpd, you won't notice a thing.

All the terrible things you may read that might happen, or that did
happen to Linux in the past, are side effects of systems that do
attempt to handle leap seconds, so that they always have the correct
time at the price of a confusing extra second popping into existence.

Finally, if you are one of the exceedingly few people for whom the
clock being off by a second actually matters, then I'm pretty sure
you also know how to deal with it.

PS:
Any hate mail about leap seconds should be directed to (1) the
people who insist that Earth's celestial wobbling around must have
primacy for time keeping and (2) the people at POSIX who specified
that time_t must not include leap seconds, which means we can't
just let the time zone database handle this.

So, once more, the answer is: don't worry, OpenBSD does the right thing. Thanks to naddy@ for taking the time to let us know.

(Comments are closed)


  1. By Anonymous Coward (176.10.104.243) on

    daddy@? Now that is an awesome typo.

  2. By Bob Beck (37.0.204.144) beck@openbsd.org on

    Naddy's a Daddy? Now that's awesome. Why wasn't that the lead to this article?

  3. By Bob Beck (37.0.204.144) beck@openbsd.org on

    Naddy's a Daddy? Now that's awesome. Why wasn't that the lead to this article?

  4. By Anonymous Coward (86.169.107.168) on

    > So, once more, the answer is: don't worry, OpenBSD does the right thing.

    No, OpenBSD doesn't do the right thing. It does a practical but wrong thing. That's what the answer pretty clearly says. So maybe take off your fanboy hat for (the leap) one second. It might be practical for many consumers. But if you (exceedingly few, really?) really have to worry about time then the solution is not to use OpenBSD and pick a system that actually does the right thing.

    1. By Anonymous Coward (92.246.18.44) on

      > > So, once more, the answer is: don't worry, OpenBSD does the right thing.
      >
      > No, OpenBSD doesn't do the right thing. It does a practical but wrong thing. That's what the answer pretty clearly says. So maybe take off your fanboy hat for (the leap) one second. It might be practical for many consumers. But if you (exceedingly few, really?) really have to worry about time then the solution is not to use OpenBSD and pick a system that actually does the right thing.

      There is a specification, it is being followed. Works as specified.

    2. By bee with fanboy hat (146.212.105.108) on

      > No, OpenBSD doesn't do the right thing. It does a practical but wrong thing. That's what the answer pretty clearly says.

      No. It does exactly the right thing and the article even tells you why; as long as time depends on an external factor, you can't handle that in a sane way. Suppose something happened to Earth's rotation and you would have to add arbitrary number of seconds.

      If you still feel the same way, please feel free to show us the code that can handle the time of 23:62:03 .

      1. By Anonymous Coward (86.169.107.168) on

        > If you still feel the same way, please feel free to show us the code that can handle the time of 23:62:03 .

        If there ever was a need to introduce more than 2 minutes of leap seconds on a single day then humanity would have far more existential issues than computer time...

    3. By Chas (147.154.235.102) on

      For anyone needing highly accurate/extreme precision time, the natural move would be to disable openntpd and revert to the reference distribution. For many others with no objections to a few seconds drift, they obtain a simpler, more rugged, and more secure daemon.

      How is chrony handling this? It appears that systemd is also dispensing with the reference ntp daemon. Declining market share may be present an opportunity for reference ntp to make some architecture changes.

      1. By Anonymous Coward (2601:186:4180:61:c4ac:685c:a0c7:c5c3) on

        > [snip] Declining market share may be present an opportunity for reference ntp to make some architecture changes.


        Isn't that what ntimed is all about?

        https://ma.ttias.be/ntimed-ntpd-replacement/

        1. By Chas (147.154.235.102) on

          Isn't that what ntimed is all about? https://ma.ttias.be/ntimed-ntpd-replacement/

          I was not aware of this project. I find the ntpd commentary quite interesting. I wish them luck!

          x Why not fix NTPD? PHK tried. But there are 360.000+ lines of code in NTPD.

          "NTPD is doomed": refactoring would not be time or resource efficient, hence the start of Ntimed. From the ground up, a good security architecture.

          Is NTPD safe? Right now: yes, most likely. Long term: no.

          NTP is probably the oldest code still running on the internet

          Ntimed [is] something to keep an eye on, before the ticking time bomb of NTPD bites us all.

    4. By Shane J Pearson (27.32.243.218) on

      > > So, once more, the answer is: don't worry, OpenBSD does the right thing.
      >
      > No, OpenBSD doesn't do the right thing. It does a practical but wrong thing. That's what the answer pretty clearly says. So maybe take off your fanboy hat for (the leap) one second. It might be practical for many consumers. But if you (exceedingly few, really?) really have to worry about time then the solution is not to use OpenBSD and pick a system that actually does the right thing.

      Which system does the right thing?

      The solutions I have seen each have their own drawbacks. Suffer drift by stopping NTPD and then restarting after the flag and then suffering a step or slow adjustment? Suffer a two second second? Suffer a code change to allow for 61 seconds in a minute, throughout your entire OS and application codebase? Preemptive slow adjustment?

      Your method of getting the square peg into the round hole is the right way when the others are wrong? They each suck in their own special way, no?

  5. By Anonymous Coward (173.174.38.161) on

    Simplicity is good. If anyone is wondering what this can look like without it, check out the advisory Aruba Networks sent to its customers over the leap second. They expect the Linux based APs they make to crash and reboot if NTP is enabled!

    http://community.arubanetworks.com/aruba/attachments/aruba/unified-wired-wireless-access/49619/1/ARUBA-PFB-20150430_Leap_Second_Field_Bulletin_Rev-3.0511.pdf

  6. By Just Another OpenBSD User (77.85.139.241) on

    About the stupidest thing to do is accounting for lame handling downstream and bend over backwards with pre-emptive skew also called "leap smear". Instead of fixing the implementations that break, cover it up... in a ciscoesque mode.

    Now you face inaccurate time before the event with an unpredictable degree of uncertainty for a while and on top of that program errors. Because we all know for a long "time" from other areas: most people can't count unless using fingers when creating programs. Including TV schedule programming.

    Then again, why not create "another" time scale with a new set of incompatibilities in a Linux fashion, no thanks. OpenBSD's OpenNTPD does the right thing, as expected.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]