Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Communications Technology News Science

You Can Look Forward To 8 More Years of Leap Second Problems (cio.com) 143

itwbennett writes: As previously discussed here, the World Radiocommunication Conference (WRC) met "for nearly the entire month of November, and one of the hot-button issues [was] what to do about the leap second." But, as they did at the 2012 conference, the WRC voted to postpone the decision — not just until the next WRC in 2019, but until the one after, in 2023, while the International Telecommunication Union conducts further studies into the impact of tinkering with the definition of Coordinated Universal Time.
This discussion has been archived. No new comments can be posted.

You Can Look Forward To 8 More Years of Leap Second Problems

Comments Filter:
  • by Anonymous Coward on Friday November 20, 2015 @01:30PM (#50970645)

    NTP handles leap seconds, where's the issue?

    • by msauve ( 701917 ) on Friday November 20, 2015 @02:58PM (#50971199)
      Actually, it doesn't. ntpd, the canonical implementation, doesn't follow the RFC for NTP. Other implementations do the same thing, simply because they're expected to be compatible with it. It does special handling for leap seconds (beyond simply advertising when they occur, so the OS can handle them properly). NTP isn't supposed to do anything with leap seconds, it's supposed to simply count seconds in an epoch. RFC 5905 says it's supposed to count seconds with a "monotonically increasing" UTC timescale.

      ntpd doesn't do that - when there's a leap second it counts backwards (or stops counting for a second, depending on how you think of it) in violation of the RFC, and then simply forgets about the leap second. It has the same fundamental flaw as POSIX.
    • by arth1 ( 260657 )

      NTP handles leap seconds, where's the issue?

      There are a lot of "foo[60]" arrays out there, and leap seconds triggering things like writing beyond the end of an array, or overwriting the last entry, losing data for the previous second. And in many cases it goes unnoticed, which can be even worse.
      Then there are interfacing between systems that handle leap seconds differently. Do you go from 23:59:59 to 23:59:60 or to a second 23:59:59? If the latter, what happens with jobs that are scheduled to run at 23:59:59.500?

      In my opinion, the solution isn't t

      • NTP handles leap seconds, where's the issue?

        There are a lot of "foo[60]" arrays out there, and leap seconds triggering things like writing beyond the end of an array, or overwriting the last entry, losing data for the previous second. And in many cases it goes unnoticed, which can be even worse.
        Then there are interfacing between systems that handle leap seconds differently. Do you go from 23:59:59 to 23:59:60 or to a second 23:59:59? If the latter, what happens with jobs that are scheduled to run at 23:59:59.500?

        In my opinion, the solution isn't to get rid of leap seconds, but for developers to not make assumptions. If you look at time.h, it states:

        int tm_sec; /* Seconds. [0-60] (1 leap second) */

        So why assume 0-59?

        I may be mis-remembering, but it seems like a summer or 2 ago, there was a day with 2 leap seconds in it.

        • by arth1 ( 260657 )

          I may be mis-remembering, but it seems like a summer or 2 ago, there was a day with 2 leap seconds in it.

          In 1972, there were two leap seconds, but one was in June and one in December, so there was no minute with more than 61 seconds. After that, there has always been 0 or 1 leap seconds per year.

        • by camperdave ( 969942 ) on Friday November 20, 2015 @10:42PM (#50973483) Journal

          I may be mis-remembering, but it seems like a summer or 2 ago, there was a day with 2 leap seconds in it.

          Not possible. The leap second committee folks have a mandate never to let the difference between the UTC and UT1 (mean solar time) readings exceed 0.9 seconds. They usually decide to apply a leap second whenever the difference between UTC and UT1 approaches 0.6 seconds. Furthermore, they can add a leap second at the end of any month, although there is a preference for June and December and a second preference for March and September. For there to be two leap seconds in a day, something catastrophic would have had to have happened, like California sliding into the ocean, the Yosemite supervolcano blowing, or the Maple Leafs winning the Stanley Cup.

      • by ceoyoyo ( 59147 )

        Heaven forbid developers actually test edge cases....

        Another solution would be to use TAI if you really can't be bothered to deal with an occasional leap second. The whole point of UTC is to have a time standard that's based on TAI but is numerically close to UT.

        I don't understand why this is suddenly a problem. Perhaps because of all the bootcamp developers writing code now?

      • by msauve ( 701917 )
        "So why assume 0-59?"

        Because, POSIX.

        The committee which created POSIX (has any "design by committee" ever gotten things right?) decided to create an impossible situation - they both define a timescale of seconds in an epoch, AND define a day to be exclusively 86400 seconds. The only way that's possible is if a POSIX system doesn't claim to maintain UTC. Most/all do.

        Here's a good explanation, with the gory details. [madore.org]

        N.B. Leap seconds existed before POSIX, so they had the opportunity to get it right. They
        • by jcdr ( 178250 )

          Exactly, you got it right. What's depressing is that, even after decades, POSIX is still unfixed.

    • I'm not particularly coordinated, and I leapt at the wrong time. So now all my clocks are off and there is nothing I can do about it until next year. I've started training to do better.

    • by AmiMoJo ( 196126 )

      A lot of industrial systems ignore daylight saving time. Too much hassle dealing with clocks jumping around when you are trying to log stuff or timestamp. Plus they keep changing the rules.

      Leap seconds are even worse. They are unpredictable. You they cause your nice GPS time sync to UTC to be ever further off. Your code has to handle occasional 61 second long minutes.

      For desktops no one much cares. For industrial/embedded systems it's a pain.

      • by jcdr ( 178250 )

        The industrial/embedded systems you describes must use TAI, not UTC or local time. Actually only the GPS broadcast the TAI in a direct usable form nearly everywhere. NTP broadcast UTC only and fail to send the TAI to UTC offset. PTP doe the right thing but is actually not broadcasted as NTP or GPS is.

    • by MSG ( 12810 )

      One of the issues if that if you need a high-resolution measurement of the real time that has passed between one event and another, it simply isn't available under POSIX systems. For scientific purposes, that sucks.

      http://www.madore.org/~david/c... [madore.org]

  • Someone should calculate how many people are studying / debating this issue and how long they've spent on it, and then see how many leap seconds each person on the planet would need to experience to match the time spent.
  • by PPH ( 736903 ) on Friday November 20, 2015 @01:35PM (#50970681)

    ... wind up the earth.

  • This is stupid ... (Score:4, Insightful)

    by gstoddart ( 321705 ) on Friday November 20, 2015 @01:38PM (#50970713) Homepage

    Leap seconds are an artifact of our timekeeping system, and actual physical properties of our orbit.

    For the ITU to be voting on if we keep leap seconds is kind of like politicians voting to determine that pi==3 ... it has nothing to do with reality.

    Like it or not, you have to solve the problem. You simply can't get a bunch of tech people on a damned committee getting together and saying "we're no longer having leap seconds". That's just stupid.

    • I agree that this is stupid, but I think the answer is "We should no longer care about calculating time with respect to the Earth's position around the sun down to the 1-second level". Who cares? Maybe once every 20,000 years we should add another leap day. But this constant fiddling with clocks for no reason just causes more problems than it solves.
      • by gstoddart ( 321705 ) on Friday November 20, 2015 @01:49PM (#50970779) Homepage

        See, the problem is most people don't understand where our system of time keeping comes from or why it's important.

        The reason we adjust for leap years and leap seconds is our calendar is a close approximation to our orbital period ... but it's not exact.

        At noon, on the day of a solstice or an equinox, the sun is in a known position in the sky. We use it for important things like navigation and timekeeping, and knowing when the hell things like eclipses, sun flares, high tides, and comets might happen ... or that asteroid which might kill us.

        It's a real physical property, which we kind of need to keep track of. It's NOT some thing you can say "oh, well, what does it matter if you're off by a couple of days?".

        • If we don't bother with leap seconds, then the distance that the sun will be off from being directly overhead at the equinox is about the same as it is now from being a couple of hundred miles away from the meridian. A simpler solution to the problem would be to, every couple of thousand years, have a one-hour reset. There is basically nothing that depends on the position of the sun in the sky to that level of accuracy, but there are a huge number of things (including all air-traffic control systems) that
          • There is basically nothing that depends on the position of the sun in the sky to that level of accuracy

            I own a sundial factory, you rotten bastard. What will my workers do if I fire them? The buggy whip manufacturers sure aren't hiring, not in this town.

            And what about my kids, I put their college fund into developing ones with luminous dials.

          • by tnk1 ( 899206 )

            Really, if anyone needs this sort of precision, they shouldn't be using calendar dates and times, they should be using epoch seconds or milliseconds. Then you can map calendar artifacts to a particular second all you want.

            Designate Jan 1 00:00 of each year as some specific second value and jitter to it. Or better, set certain dates of the year to less than a second and jitter to those.

          • If we don't bother with leap seconds, then the distance that the sun will be off from being directly overhead at the equinox is about the same as it is now from being a couple of hundred miles away from the meridian. A simpler solution to the problem would be to, every couple of thousand years, have a one-hour reset.

            Actually, the problem is worse than that (and shows the futility of the leap second system), because the earth is of course slowing down [wikipedia.org].

            So, while we now have to add a leap second every few years or whatever, eventually that will become every year, then two every year, and then the current system will break, because right now we're only allowed two leap seconds per year by the current standard.

            At best, adding up to two leap seconds per year will be able to keep up with the slowing earth for about anothe [ucolick.org]

            • by jcdr ( 178250 )

              The current leap second system is still enough for many centuries and even several thousand of years is the leap seconds are allowed every months or weeks.

              Is you think about this more deeply you will realize that the best model will be to have what we actually call UTC defined in term of days counter since a epoch date and a second counter since the start of that day. This will allow to adjust periodically the day duration to the reality of the average earth rotation. Not only this model work with the earth

          • by ceoyoyo ( 59147 )

            There are lots of things that depend on the position of the sun and stars to sub-second accuracy. Celestial navigation, pointing telescopes, pointing satellite dishes.

            I don't buy the objections to using UTC. If you can't code a safety critical system for leap seconds, you probably shouldn't be coding safety critical systems. Note that it hasn't been a big problem for the last thirty years, why is it now?

            If you REALLY can't deal with leap seconds, use TAI. That's why it exists.

          • by Bengie ( 1121981 )

            If we don't bother with leap seconds, then the distance that the sun will be off from being directly overhead at the equinox is about the same as it is now from being a couple of hundred miles away from the meridian.

            How is that an issue? How does this affect humans on the other side of the Universe that need to have a unit of time defined as a "day"? We should use a unit of time that is useful for humans yet is not tied down to what is happening on Earth.

        • The reason we adjust for leap years and leap seconds is our calendar is a close approximation to our orbital period ... but it's not exact.

          That's the reason we adjust for leap years. The reason we adjust for leap seconds is that the speed of the earth's rotation 1) isn't exactly 360 degrees in 86400 SI seconds and 2) changes over time, so it's not even a fixed value close to 360 degrees in 86400 SI seconds.

          • The reason we adjust for leap seconds is that the speed of the earth's rotation 1) isn't exactly 360 degrees in 86400 SI seconds and 2) changes over time, so it's not even a fixed value close to 360 degrees in 86400 SI seconds.

            The earth rotates approximately 360 degrees in one sidereal day. But since the earth is orbiting around the sun, it needs to rotate approximately 361 degrees per solar day. The leap second is not to account for this difference. The leap second accounts for variation in the mean solar day relative to the average mean solar day when the standard second was established.

        • by Anonymous Coward on Friday November 20, 2015 @03:02PM (#50971227)

          We use it for important things like navigation and timekeeping, and knowing when the hell things like eclipses, sun flares, high tides, and comets might happen ... or that asteroid which might kill us.

          I'm a professional astronomer, who occasionally needs to time things to sub-second precision over multiple years - and the leap second is, to me, nothing but a pain in the arse. Let's run down your list:

            * "navigation" - No one navigates by the sun and stars any more - at least, certainly no one who needs sub-second precision.

            * "timekeeping" - Atomic clocks keep time irrespective of the sun.

            * "eclipses" - Eclipses don't care whether the sun's at the meridian or not: they only care about the relative position of the sun and the moon, which you can calculate perfectly easily with an arbitrary time standard.

            * "sun flares" - Solar flares don't care whether the sun's at the meridian or not.

            * "high tides" - The sun makes a small contribution to the tides (which are dominated by the moon), so the leap second *does* help you keep track of this contribution - but who the hell needs to know the high tide to the nearest second?

            * "comets" - Comets don't care if the sun is at the meridian or not.

            * "that asteroid which might kill us" - That asteroid doesn't care if the sun is at the meridian or not - but there *is* a chance that someone might miscalculate its orbit and not realise that it's going to kill us, because there was a bug in their code dealing with leap seconds.

          So, this is something that genuinely puzzles me: who actually *wants* leap seconds? You seem to think that I should want them, but I certainly don't.

          • by ceoyoyo ( 59147 )

            I'll agree with you on the rest of the list, but I personally have navigated using the stars, requiring to-the-second accuracy.

            • by Yxven ( 1100075 )

              Would you expand on this? It sounded like a reasonable assumption to me. If you're saying there are situations where it's not reasonable, it'd be nice to know what those situations are.

              • by ceoyoyo ( 59147 )

                Reducing a sight in modern celestial navigation usually involves calculating the expected altitude of a target celestial body at a particular time at a particular place on the surface, noting the actual altitude of the body, then using the difference to determine your distance from the reference location. To do that you need to use a time standard that stays in sync with the heavens, or correct for the drift in one that doesn't. UTC is convenient because it's accurate to about a tenth of a second, as clos

                • Why not just keep a separate clock for these purposes and let the rest of us be?

                  • by ceoyoyo ( 59147 )

                    UTC IS the separate clock kept for those purposes. If you don't like leap seconds, set your clock to one of the half dozen time standards that don't have them.

        • by Kjella ( 173770 )

          At noon, on the day of a solstice or an equinox, the sun is in a known position in the sky. We use it for important things like navigation and timekeeping, and knowing when the hell things like eclipses, sun flares, high tides, and comets might happen ... or that asteroid which might kill us. It's a real physical property, which we kind of need to keep track of. It's NOT some thing you can say "oh, well, what does it matter if you're off by a couple of days?".

          But we're not talking about days. There's been 26 leap seconds in 43 years, we're talking about a drift of roughly one minute per century. For most things being off by a minute or two wouldn't matter and if you know 12:01 = 12:00 a hundred years ago it might be easier to correct for that. While leap seconds keeps us in sync with reality, it means that if you want to do something every X seconds you can't just rely on UTC and NTP because at some point it'll actually go X+1 seconds. And leap seconds take worl

      • by Jamu ( 852752 )
        I think the mistake was trying to use a fixed time-period for seconds. It might work for angles, but it's a mess when it comes to variable lengths like days or years. The second should just be a fixed fraction of today or the current year, and we should give up a conflating it with a unit of time. The SI "second" is a good unit time, similar to a second, and badly named.
        • A second used to be 1/86,400 of a mean solar day (e.g. high noon to high noon). A slowing day would mean a lengthening second, which would screw up measurements of basic physical constants, e.g. the speed of light.

          The current definition of a second is http://physics.nist.gov/cuu/Un... [nist.gov]

          > The second is the duration of 9 192 631 770 periods of the
          > radiation corresponding to the transition between the two
          > hyperfine levels of the ground state of the cesium 133 atom.

          In theory, any sufficiently advanced

      • by ceoyoyo ( 59147 )

        If you're aiming a telescope, or a satellite dish, or computing an almanac, you care. The point of UTC is that it stays close to UT so that the people who need a time standard that's aligned with the actual rotation of the Earth have something to use. If you don't want to deal with leap seconds, there's already a standard for that. It's called International Atomic Time (TAI), and has been around since the early seventies.

    • by Anonymous Coward

      No it isn't stupid. You may think it sounds stupid - but that is due to your ignorance. There are real considerations in determining whether to keep or end the addition/subtraction of leap seconds. Continuous time scales are fundamental to a number of navigation & economic operations.

      • No it isn't stupid. You may think it sounds stupid - but that is due to your ignorance

        That's OK, you're an AC and therefore I assume you're a moron.

        Continuous time scales are fundamental to a number of navigation & economic operations.

        You do understand that the navigation is ALSO intrinsically tied to the astronomical positioning of things, right?

        That it causes problems for computers is a relatively modern problem. Keeping accurate track of the time as it relates to the actual sky has been with humans

        • You do understand that the navigation is ALSO intrinsically tied to the astronomical positioning of things, right?

          Today? Mostly (for anything where accuracy matters to the degree that leap seconds will make a difference in under a few hundred years) it depends on the GPS position, or some equivalent. GPS time, unlike UTC, does not have leap seconds.

          • GPS time actually doesn't exist, because clocks in orbit differ from clocks on the ground, due to Relativity. There is no "GPS" time, and in fact, the differences in time keeping between clocks is integral to how GPS actually works.

            • by jbengt ( 874751 )
              There is a GPS standard time. I believe it is based on the Geocentric Celestial Reference System. (as opposed to the Barycentric Celestial Reference System that you may need for positioning beyond Earth orbit.)
              Anyway, if you don't like that, you could use the TAI (International Atomic Clock Time) instead.
              Leap seconds can be used for displaying time in UTC if you need to, while those that need a constant, uninterrupted tick of the clock could use TAI (or GPS) in the backend.
          • by ceoyoyo ( 59147 )

            GPS satellites report a time that is a strict offset of TAI, which is the standard that is designed for use by people who don't want leap seconds. GPS positioning depends on the precise position of points on the surface of the Earth underneath the GPS constellation, so although the satellites report a TAI-locked time, to actually determine your position you have to do a correction that's very similar to UTC, except with a granularity that's more like leap nanoseconds instead of seconds.

    • like politicians voting to determine that pi==3 ... it has nothing to do with reality.

      It's irrational to try to redefine the irrational as rational.

    • by PRMan ( 959735 )
      There have been only 25 leap seconds since 1972 (43 years). Why don't we just add 1-3 seconds on leap day instead? Time's already screwed up that day anyway.
    • by petermgreen ( 876956 ) <<ten.knil01p> <ta> <hsawgulp>> on Friday November 20, 2015 @03:51PM (#50971469) Homepage

      Leap seconds are an artifact of our timekeeping system, and actual physical properties of our orbit.

      The latter we are stuck with but the former is something humanity has the power to change. There are basically three choices.

      1: Disconnect the civil time second from the SI second. Allow the civil time second to vary slightly to match the mean solar day.
      2: Allow civil time to drift relative to solar time
      3: Make periodic adjustments to civil time to keep it close to solar time.

      Each choice hurts different people. Choice 1 hurts anyone who needs to convert between civil time and "atom time". Choice 2 hurts people who rely on civil time as a navigational aid and future historians. Choice 3 puts a rarely excersised special case into computer systems leading to systematic failures.

      • by jcdr ( 178250 )

        1) Will lead to many more confusion between the two type of seconds.
        2) Will break the ancestral definition of time in all the civilization that ever existed.
        3) The only way and nobody is seriously make any other proposition. The discussion is how to improve it because the leap second is rare enough to make too many programmers not taking it seriously enough and testing is enough.

        So the solution is certainly not to make the adjustment more rare, but more often. My proposal is to define the civil time by a da

    • Better yet, we need to FIX POSIX time not mess up UTC. Leap seconds are currently not representable in posix time.
  • Call me strange but I find it hard to imagine that a computer clock being a second off for a moment is anything but invisible to your average software developer/IT worker/server farm.
    I mean if your computer's clock is set up to sync with an NTP server every now and again, your system is probably already seeing corrections of that scale and more.

    • Re: (Score:2, Interesting)

      by Hognoxious ( 631665 )

      It's never given me any problems.

      Then again, I'm not the kind of person who writes my own date/time validation routines because daylight saving is part of Agenda 21 and fluoride causes autism. I suspect it's them making most of the noise.

    • by rsborg ( 111459 )

      Call me strange but I find it hard to imagine that a computer clock being a second off for a moment is anything but invisible to your average software developer/IT worker/server farm.
      I mean if your computer's clock is set up to sync with an NTP server every now and again, your system is probably already seeing corrections of that scale and more.

      I would imagine that advanced scientific calculations as well as high-frequency-trading algorithms would be affected. Clearly the scientists can go fuck themselves, but I'm surprised that the needs of something as important as HFT has gone unheard in the WRC/ITC.

      • by ceoyoyo ( 59147 )

        Why would a scientific calculation care about what time it is? Unless you're talking about astronomy, in which case astronomers have lots of time standards, and actually know how to use them.

    • by Anonymous Coward

      Yes, leap seconds ruined my first marriage.

  • You Can Look Forward To 8 More Years of Leap Second Problems

    I'm pleased to see others making this point, but personally I've never had any leap second problems, so I don't know who you're talking to, Mr Click-bait Headline.

    • I can't speak for anybody else, here, but I find the headline reassuring. I'm in my mid-60s and my health isn't too good (I take 27 pills per day, all prescription, plus insulin.) so the fact that I can look forward to being here for another eight years is good to know.
  • by at10u8 ( 179705 ) on Friday November 20, 2015 @01:59PM (#50970837)
    The first proposal to abandon leap seconds was presented to the ITU-R in 2004, and subsequent versions have been rejected for over a decade. It is evident that the usual process of ITU-R decisions is not capable of coming to agreement on the subject of leap seconds. It remains to be seen whether they will produce a new framework for studies which can produce an agreement in 8 years.
    • by jcdr ( 178250 )

      It's not the usual process of ITU decision that is the cause of the rejection. The cause is the fact that the proposition itself is stupid and make the problem even worst. To be certain that the programmers take seriously the fact that the duration of day is variable the adjustment code path must occur more often. The most effective way will be to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically. The programmed will know that the

  • As I see it, this is a question about standardizing and implementing systems properly. Leap seconds are announced months in advance.

    It can't be such a big problem systems that handle this correctly.

    But then, daylight savings time still seems to give problems. Sheesh!

    virve

    PS. Anybody who knows about problems with leap days?

    • Leap seconds are announced months in advance

      i.e. with less warning than the revalidation time for a lot of safety-critical systems.

      Anybody who knows about problems with leap days?

      Well, aside from the Zune infinite looping...

      Leap days (which we call leap years, because consistency is hard) are predictable. Software written 40 years ago will have the extra days at exactly the same times and with exactly the same frequency that the designers thought that they would. You never have problems where some parts of a distributed system got the update and others didn't. Either the code is working, or i

      • Leap days (which we call leap years, because consistency is hard) are predictable. Software written 40 years ago will have the extra days at exactly the same times and with exactly the same frequency that the designers thought that they would. You never have problems where some parts of a distributed system got the update and others didn't. Either the code is working, or it's broken. It's also really easy to test.

        Actually, I wonder how much software written 40 years ago correctly calculates leap years. Every year divisible by 4 is a leap year, except for those divisible by 100, except those divisible by 400. How much software will consider the year 2100 a leap year because the algorithm was dumbed down to every four years?

        • Every year divisible by 4 is a leap year, except for those divisible by 100, except those divisible by 400. How much software will consider the year 2100 a leap year because the algorithm was dumbed down to every four years?

          Actually, that rule is only true of the Gregorian calendar. Many countries have never officially adopted the Gregorian calendar, but rather use the Revised Julian Calendar [wikipedia.org], whose rules say that you only have leap years in centennial years when the year number/100 MOD 9 comes out to 2 or 6.

          (This was done because the Revised Julian algorithm produces a much more accurate approximation to the true year than the Gregorian calendar.)

          The Revised Julian Calendar and the Gregorian Calendar line up in their rul

          • Sorry to self-reply, but I should clarify that I believe most if not all Western countries have officially adopted the Gregorian calendar. But a number of countries with strong presence of Orthodox Christians have official churches which have instead adopted the Revised Julian. There have been some politicians in these countries which have claimed the official calendar is not Gregorian...

            Obviously it's probably unlikely that anyone is going to care about this stuff 800 years from now. It's still an amu

            • Sorry to self-reply, but I should clarify that I believe most if not all Western countries have officially adopted the Gregorian calendar. But a number of countries with strong presence of Orthodox Christians have official churches which have instead adopted the Revised Julian. There have been some politicians in these countries which have claimed the official calendar is not Gregorian...

              Obviously it's probably unlikely that anyone is going to care about this stuff 800 years from now. It's still an amusing bit of weird calendar discrepancies.

              The new calendar has been adopted by the Orthodox churches of Constantinople, Alexandria, Antioch, Greece, Cyprus, Romania, Poland, and Bulgaria (the last in 1963), called the New calendarists. It has not been adopted by the Orthodox churches of Jerusalem, Russia, Serbia (including the uncanonical Macedonian Orthodox Church), Georgia, Mount Athos and the Greek Old Calendarists. Although Milankovi stated that the Russian Orthodox Church adopted the new calendar in 1923, the present church continues to use th

      • by virve ( 63803 )

        Leap seconds are announced months in advance

        i.e. with less warning than the revalidation time for a lot of safety-critical systems.

        Hmm., hopefully safety-critical systems are implemented so that they have provisions for leap seconds built in already. What should be needed is organizational procedures for setting the appropriate flag in time.

        Further, I would expect that many safety-critical systems are more concerned with elapsed time from some epoch (switch on, last firing of engine, last heart-beat) and less about civic(?) calender time (we meet on January 2nd, 2016 11:01:14 EST).

        Finally, in really hairy cases things should be referre

  • That sub-second syncronization is integral to the function of both GPS and the internet right? If we didn't account for relativistic variation in the timing of events between satellites and position on earth, GPS would completely non-functional. So yes, this is important. It simply isn't visible to the average user, even in IT. We don't need to deel with it because the low level programmers already have.
    • > That sub-second syncronization is integral to the function of both GPS

      No. GPS does NOT use leap seconds.

      what-if xkcd #26 [xkcd.com] is actually on-topic for once.

      • No, it doesn't. It is, however, an example of an area where this sort of thing matters.
      • by ceoyoyo ( 59147 )

        GPS satellites report time that does not include leap seconds. But your GPS receiver has to make corrections to that time that are much more accurate than leap seconds to give you the correct position on the Earth's surface.

      • by jcdr ( 178250 )

        GPS and PTP both broadcast TAI and UTC-TAI that sum up the past leap seconds, so your claim is not completely correct. I will add that GPS and PTP both lack a method to broadcast the leap second history table required to safely compute time in the past at the second precision. NTP need a major protocol upgrade to fix his multiples issues, or PTP need to be broadcasted as NTP is today.

  • If your system's incapable of proper leap second handling and major changes are considered too costly? Then quit barking up the wrong tree and switch to TAI [wikipedia.org]! UTC-based time is intended for humans, y'know.
  • Good. 8 more years of time working correctly. The fundamental issue is that the Earth just doesn't care what our atomic clocks measure. If programmers want an exact time system without leap seconds, use TAI, that's what it's for. Most people in the world don't care if it's hard to code leap seconds. Instead, most people go outside occasionally, and they expect that 'noon' means approximately 'sun at highest point'. We can switch to some system other than leap seconds, but if we expect 'noon' to have its conventional meaning, then we need to agree on a system that does that.
    • Good. 8 more years of time working correctly. The fundamental issue is that the Earth just doesn't care what our atomic clocks measure. If programmers want an exact time system without leap seconds, use TAI, that's what it's for. Most people in the world don't care if it's hard to code leap seconds. Instead, most people go outside occasionally, and they expect that 'noon' means approximately 'sun at highest point'. We can switch to some system other than leap seconds, but if we expect 'noon' to have its conventional meaning, then we need to agree on a system that does that.

      Except that system is NOT UTC. The system where "noon" means "sun at highest point" is called UT1 [wikipedia.org]. UTC is the "smoothed out" version of UT1 that allows an error up to a second.

      Other than astronomers, nobody really cares about UT1. Nobody really cares about the 1-second error in UTC either when it comes to "noon." Heck, most countries shift where the sun is at noon twice each year to observe "daylight savings."

      The question is whether there is any practical benefit to keeping UTC within 1 second of UT

      • by ceoyoyo ( 59147 )

        How do you know about the difference between UT1 and UTC, and not know that your hypothetical non-leap second corrected time standard has existed for more than forty years and is called TAI?

    • I agree. The problem is not UTC or leap seconds, it is that POSIX time ignores the existence of leap seconds [wikipedia.org]. The more appropriate fix to me would be to redefine POSIX time as TAI. Or more accurately obsolete POSIX time so programmers are forced to choose between TAI and UTC. Who would ever have tried to convert from posix time to year/month/day/hour/minute without a library anyway?
    • If programmers want an exact time system without leap seconds, use TAI, that's what it's for.

      No, it is not intended for programmers (as a monotonic clock without daylight savings and leap seconds), or as an alternative to UTC. The TAI, International Atomic Time [wikipedia.org], is a time standard based on the coordination of approximately 400 atomic clocks from government labs around the world (50+ counties). It has never been intended to be a time standard for general usage.

      Universal Time [wikipedia.org] (UT) in its several variants (UT0, UT1, UT1R) are more likely to be appropriate, but UTC is still the best solution for being

  • by JoeyRox ( 2711699 ) on Friday November 20, 2015 @03:27PM (#50971339)
    Give or take a second.
  • Come on Slashdot! itwbennett is the new nervals lobster schill on /. All of his posts link to ITWorld or cio.com, both owned by the same company. At least disclose these ties. We know Dice is hurting for cash to pay their execs their $1 million salaries but this is just ridiculous. You are alienating and losing your most loyal users and soon there will be nothing left.

  • Rather than worrying about leap seconds all we really need to do is slightly alter the rotation of the earth to make it an exact 24 hour rotation. Problem solved.

  • If the OS and / or applications can't handle a leap second, then it should be fixed. Nothing should ever be changed to make up for the shortcomings of bad code.

  • Don't Use UTC (Score:3, Interesting)

    by Greyfox ( 87712 ) on Friday November 20, 2015 @07:45PM (#50972685) Homepage Journal
    So just don't use UTC. The POSIX group only said "UTC" instead of "GMT" because they didn't know they difference and they thought saying "UTC" made them sound cooler. A lot of companies put it in their specs for the same reason. They're all like "Ooo we're all technical because we're using UTC!" Then you ask them if they're really using UTC or GMT and they ask you what the difference is. The only people it really matters for is NASA, and they convert from a well known time system to another well known time system as they need to. Most programmers just need to know the number of seconds since Midnight, Jan 1, 1970, GMT, as God intended.
    • Are you sure YOU know the difference between UTC and GMT?

      It's not that UTC sounds cooler... It's what we actually use. UTC ticks based on atomic clocks and it's what's distributed through NTP. GMT (really UT) tracks Earth's rotation, doesn't have a stable second, and there are no high-precision realtime references.

      Most programmers just need to know the number of seconds since Midnight, Jan 1, 1970, GMT, as God intended.

      time_t doesn't count the number of absolute SI seconds since the Epoch: it assumes days are always 86400.0 seconds long, and completely ignores leap seconds... even worse, before 1972 they used

      • by Greyfox ( 87712 )
        Well the major languages I looked at (C, Java, Perl) just ignore leap seconds, as does the POSIX standard. If you ignore leap seconds, you're not UTC and saying you are is incorrect. Maybe you're actually just TAI, but probably not since the language APIs don't know about SI seconds and work on the assumption that there are 86400 seconds in a day. But since it's a linear timescale, I can at least convert to and from another one when doing astronomical calculations.

        I haven't checked but I suspect the situat

  • Do you have any IDEA what a mess Daylight Savings Time makes of things like programs for process control and scheduling - and has at least since I did software for it back in the late '70s

    Heck: For far longer than that. I hear the railroads handle it like this:
      - In the spring, suddenly all the trains are an hour late. They work their way back to being on-time as they normally would - by running as fast as is practical.
      - In the fall they STOP FOR AN HOUR. They just sit there with their engines running...
    It's just easier than trying to figure out something "better" to do about it.

    The claims that it saves energy are currently backward and getting more so. They may always have been, or it may be because lighting is more efficient (so the savings is small) while air conditioners are far more prevalent (and run more if people get home earlier).

    Meanwhile it increases death rates: From DST-lagged drivers just after a change, from kids getting hit going to school in the dark on more days, from stress-related diseases exacerbated by the stress of the time change.

    It also was a big factor in killing drive-in theatres.

    If the government MUST twiddle with the clocks seasonally they should set them the OTHER WAY, creating Night Life Savings Time. We ALREADY have a shortage of dark time for evening recreation in the summer. Why take another hour away by shifting the clocks? Add one instead.

Lo! Men have become the tool of their tools. -- Henry David Thoreau

Working...