Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Communications News Science Technology

Leap Second May Be On the Chopping Block (ieee.org) 291

Posted by Soulskill from the look-before-you-leap dept.
szotz writes: The days of 61-second minutes may be coming to an end. The World Radiocommunication Conference is meeting for nearly the entire month of November, and one of the hot-button issues is what to do about the leap second. The addition to UTC is supposed to keep atomic time aligned with Earth's rotation, but past leap seconds have caused server crashes, and some are worried that future problems could be even worse. Going into the conference, it doesn't look like there's much of a consensus on what to do. One official is expecting weeks of debate.
This discussion has been archived. No new comments can be posted.

Leap Second May Be On the Chopping Block More

Leap Second May Be On the Chopping Block

Comments Filter:

  • It's not the Earth's fault (Score:5, Insightful)

    by plover ( 150551 ) on Friday October 30, 2015 @10:10AM (#50832543) Homepage Journal

    So people write crappy code and rely on it without adequate fault tolerance strategies and that's somehow the problem of people who measure time? I think not.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      There will certainly be lots of problems if and when software is required to cope with relativity of time.

      But, whenever that does happen, it is certain there will be people complaining the old code is crappy because it does not take the necessary details into account.

    • Re:It's not the Earth's fault (Score:5, Interesting)

      by rainmaestro ( 996549 ) on Friday October 30, 2015 @10:36AM (#50832751)

      This is a large part of the problem. More often than not these issues stem from people trying to roll their own time handling code / int'l address code / i18n / etc rather than using one of the standard (and well-tested) libraries available in their language.

      Time is hard to get right, addresses are hard to get right, i18n is hard to get right. Don't roll your own. There's a thousand edge cases you haven't accounted for.

      • Re: (Score:3)

        by 0123456 ( 636235 )

        This is a large part of the problem. More often than not these issues stem from people trying to roll their own time handling code / int'l address code / i18n / etc rather than using one of the standard (and well-tested) libraries available in their language.

        Uh, no. Not in the least.

        Most of these issues stem from operating system bugs which are only triggered by leap seconds, which can't easily be tested before the leap second happens. We had to get special firmware from our GPS manufacturer to get it to send out NTP packets that simulated a leap second, so we could do that.

        And even when you have backup systems, they fail at the same time, because the leap second happens everywhere at the same time.

        They're a freaking disaster, and anyone who cares about them ca

        • Can you describe such a bug?
          I find it hard to believe that a leap second can crash any computer.
          What should be the difference when NTP tells me it is time X and my clock was off one second, or it tells me it is time X and my clock is off one second because of one leap second?

          Unless I get time synchronizations from the outside, I would not even know the rest of the world leaped one second forward.

          • Re: (Score:2)

            by jandrese ( 485 )
            The classic case is when you have a computer with an event loop and the leap second causes the timing to get messed up on the loop causing a double event or sometimes freezing it entirely. There were a number of websites that crashed during the 2012 leap second, including some airline ticketing systems. The 2015 event seemed less dramatic overall, but there were still a few reports of crashes.

            Google implemented an interesting strategy in 2015. They simply drifted their clocks over a 12 hour period in

      • More often than not these issues stem from people trying to roll their own time handling code / int'l address code / i18n / etc rather than using one of the standard (and well-tested) libraries available in their language.

        In some cases, the well-tested library is a third-party library that ships with neither the language nor the default install of the operating system. This leads to "I couldn't get the application to start because I couldn't figure out how to follow the instructions to install the required third-party library" or "I couldn't get the application to start because I lack privileges to install the required third-party library." A company may think rolling one's own good enough library is cheaper than fielding th

      • Re: (Score:2)

        by plover ( 150551 )

        This is a large part of the problem. More often than not these issues stem from people trying to roll their own time handling code / int'l address code / i18n / etc rather than using one of the standard (and well-tested) libraries available in their language.

        Time is hard to get right, addresses are hard to get right, i18n is hard to get right. Don't roll your own. There's a thousand edge cases you haven't accounted for.

        That may be fine advice for time formatting and time stamp storage routines, but how a system should behave when it's reference time is altered is a business logic decision. I might be working on a response time routine for approving credit, while you might be working on lag time between players in a FPS game; neither of which is a problem that's solved in a library. And if you think that Kerberos and LDAP systems handle this stuff properly today, you're also in for disappointment.

        Some of this stuff still n

      • Time isn't hard to get right. We have just done done a wonderful job of making it complicated. A second is defined as a fixed period of time based on what was thought to be 1/60th of 1/60th of 1/24th of a day. As we get better ways of accurately measuring a day, we just haven't redefined it.

        1) Redefine a second to account for leap seconds, leap centuries, and any other extra corrective increments we might need to apply. We now know really well how to measure the Earth's rotation accurately, and we could

        • Time isn't hard to get right. We have just done done a wonderful job of making it complicated.

          Also known as, we've made it hard to get right. We're not talking about time in the abstract, we're talking about our implementation of it being hard to get right because we have complicated the hell out of it.

        • Re: (Score:2)

          by JazzLad ( 935151 )

          everybody in the word getting up at 8 am and going to bed at 10 pm

          Mmm, 10 hours of sleep a night, sign me up!

        • Perhaps you should read a bit about calendars.
          E.g. when and why the Gregorian calendar was introduced.
          I personally find it quite comfortable that in local time the sun is straight ahead above me. Regardless where I am. E.g. I don't have to mess around when sailing. South or north, depending where you are, is easy to figure.

          I don't get why idiots always proclaim 'time solutions' for the world.

          I suggest you put your watch to UTC. And life a year without adjusting it.

          A friend of mine did that, but gave up afte

        • ... 500 years from now, the winter solstice might be in June in the Northern Hemisphere, but honestly, who cares?

          Father time.
          He is pissed off and wants to talk to you about this insensitive post.

        • We can't redefine time because time is already defined as how long it takes for light to travel 3 gazillion meters in a vacuum.

      • "But I'm smarter than other people, it'll be easy!", they all say.

    • that'll hold the little bastards

    • remember how Y2K was supposed to crash all civilization because bad code in the bowels of all infrastructure and control systems could not deal with the rollover from 1999 to 2000? That didn't happen much. I am still here. How is it that a 1 second error brings down a server?

      • Because the Y2K bugs got fixed.
        The one second leap second bugs: not.


                if (xx15

        Playing with various values of 19 and 20 for xx and yy and figure what would go on is left as an excersise for you!

    • The ITU-R first received this issue as Question 236/7 in year 2001 [itu.int]. They have spent nearly 15 years coming up with this list of 6 methods for dealing with leap seconds [acma.gov.au]. In that note the most recent "Method D" from a group of countries who prefer no change because they are not satisfied with the documents that have been submitted to the ITU-R during the past decade.

      The debate continues because it is not a technical issue. We know how to count SI seconds by physicists watching cesium atoms, and we know how

    • Re: (Score:2)

      by reanjr ( 588767 )

      You mean like when they created time zones just for the rail industry?

  • Isn't this an old problem solved by unix ages ago? If the computer goes off line from the network, it comes back and its local clock has drifted away from other computers... it happens all the time and it used to happen lot more often in the early days. The computer speeds up its clock imperceptably and achieves full synch in so many hours or days as specified by the sys admin.

    So the means to synch the servers exist, right? Or is this very out of date view of computer and the clocks?

    • The problem isn't the system, it is the software and databases that require millisecond accuracy.

      The problem is that time is not as linear as we think it is. Even accurate clocks can start having time shifts in relation to each other. This is all spelled out in Physics and is (or at least, should be) well known.

      We need to change how we keep track of time, in a way that isn't linear.

      • The problem isn't the system, it is the software and databases that require millisecond accuracy.

        There have been issues with the kernel in the past.

        https://rhn.redhat.com/errata/... [redhat.com]

        The problem I saw was a lot of servers suddenly increased their cpu usage.To clear it you had to set the time to the current time(date -s "`date`").

      • >We need to change how we keep track of time, in a way that isn't linear.

        The problem with this is that time is linear. That's why time machines don't work. Yes, there are spooky quantum effects, and maybe when the servers and desktops are all quantum computers new solutions will present themselves.

        • Re: (Score:2)

          by sjames ( 1099 )

          No, it isn't. Put an atomic clock on Earth and another in orbit. They will disagree soon enough. They will both be right.

      • Re: (Score:2)

        by plover ( 150551 )

        We need to change how we keep track of time, in a way that isn't linear.

        Asynchronous clocks! I love this idea! Instead of every system implementing its own real time clock, every computer on the planet will instead constantly poll a universal clock service, and supply that digitally signed millisecond to all of its processes.

        The truly sad part is that I know there's some SaaS weenie out there who fervently believes this is a good idea.

      • The problem isn't the system, it is the software and databases that require millisecond accuracy.

        Many systems can be implemented without time synchronization, and many systems that rely on it don't need to. But there are classes of distributed problems that cannot be solved, or cannot be solved as efficiently, without a sufficiently-accurate shared reference time.

        Google has an interesting solution to this problem, first implemented in 2008, called the "leap smear". Over a 20-hour window centered on the leap second addition, the servers' clocks are skewed slightly slower so that for each second of re

    • Re: (Score:2)

      by arth1 ( 260657 )

      Isn't this an old problem solved by unix ages ago?

      No. Time drift is, but extra seconds aren't.
      Some programs may have hardcoded limits for seconds being in the 0..59 range, and will do unexpected things if a second value suddenly is 60.

      Imagine something like an array of seconds, dimensioned to 60 elements. Ka-boom.

      Or just look at the standard date command:
      date -d "23:59:60"
      date: invalid date `23:59:60`

      If we want to synchronize a common time with the orbit of the planet, we either need to add or remove time (like leap seconds), or speed up and slow down th

  • Let me think about it for a second .... (Score:3)

    by pollarda ( 632730 ) on Friday October 30, 2015 @10:15AM (#50832585)

    While I'm sympathetic for all the folks who want to drop the leap second, given an appropriate amount of time the difference will add up. It seems to me the problem is quite simple which is to publicize the leap second a bit more than it is now. It is an education issue -- at least no more or less than leap days and that seems to work just fine all in all.

    Perhaps Facebook can create a viral leap second post. Much better than viral kitty posts.

    • Re: (Score:2, Funny)

      by Anonymous Coward
      Pass a law saying all bars / taverns / pubs are not allowed to charge money for drinks served during the leap second. It'd get plenty of publicity.

    • Re:Let me think about it for a second .... (Score:5, Interesting)

      by Anonymous Coward on Friday October 30, 2015 @10:39AM (#50832791)

      The problem with leap seconds vs. leap days is that leap seconds do not follow a regular pattern. It's fairly simple to write code that follows the leap year rules: February 29 occurs when (year mod 4 == 0 and year mod 100 != 0) or year mod 400 == 0

      The timing of leap seconds, on the other hand, are chosen on a case-by-case basis by some standards body (IERS) and announced, usually with only about six month's notice. Thus hardcoded rules for leap seconds are not a good idea, and you have to have some means of distributing leap second announcements to all systems where clock accuracy is critical. Either that or you accept a one-second margin of error, don't count the leap second and correct the clock later.

      • Hopefully you realize that leap seconds are not "chosen by a standards body" per se, they are actually measurements of the slow-down of the earth's rotation and the standards body just decides how to schedule them. As another poster said, if you don't need to know the time of day, don't convert to UTC, just use a time standard that doesn't have leap seconds. The problem here is ignorant people who don't realize that time of day is not easily derivable from time-since-epoch. Changing from leap seconds to

        • Re: (Score:2)

          by amorsen ( 7485 )

          Changing from leap seconds to leap minutes would move the problem from NTP to time zone files. Time zone files are well tested, regularly updated, and generally high quality.

          We have high quality libraries which can calculate the time difference between two arbitrary times in different time zones. This is not possible for leap seconds, because they do not get scheduled in with a decent amount of warning. Changing time zones is tested in many locales twice a year, it basically never breaks.

  • I'm majorly confused (Score:5, Insightful)

    by holophrastic ( 221104 ) on Friday October 30, 2015 @10:24AM (#50832663)

    In my 35 years, I've always seen time as a counted measure of how much time has passed since I started counting. I seem to be forever learning that's my novel idea.

    Why should I care where the sun is, where the moon is, where the earth is, with respect to time? If it's winter, I can start work at 9, I can start at 10, I can start an hour after sunrise. I don't need to adjust my clock to start work at the same clock-display every day. I see nothing wrong with a company that has different business-hours by the season.

    Similarly, since I'm not in the old west, I don't care if "high noon" is an noon, or 1, or 1 second after noon. I've never determined the time based on the sun.

    Last I checked, we have perfectly wonderful time-keeping and gps devices these days. So ocean ships and submarines no longer need a sextant and a chronometer to figure out when and where they are.

    So here's my petition. I'd like time to always move forward, and the same rate of 1 second per second. I'd like it to not jump, leap, crawl, rewind, fast forward, restart, end , or eject.

    Shit, I just realized that I'm not 35 years old. Or I am 35 years old, but not when measured in seconds. Wait for it...ok, now I'm 35 years old. Phew.

    • Why should I care where the sun is, where the moon is, where the earth is, with respect to time?

      Because the primary function of time since the dawn of civilization has been to allow human activity to synchronize with the position of the sun, from planting seasons to night watches.

      If it's winter, I can start work at 9, I can start at 10, I can start an hour after sunrise.

      If you never leave the server room, perhaps. Most human beings have lives that are affected by sunlight. At the very least commuting in li

      • In those cases, where your plans are based on the sun, you ought to be basing your schedule on the sun.

        You can easily start work an hour after sunrise. If the sun matters to you, you'll skip the days when it's raining, or you'll wait for the rain to pass.

        "we leave at first-light" means when you can see, not when the sun is blocked by clouds.

        Say what you actually mean.

        But the primary function of time today, is not to synchronize activity with the sun. Today, it's to synchronize human activity with other hu

        • But the primary function of time today, is not to synchronize activity with the sun. Today, it's to synchronize human activity with other human activity, often across great distances.

          It's both. It's to synchronize human activity with other human activity, some of which also happens to be synchronized with the sun over the course of about a week.

          The number of broadcast networks who said "the game starts at 7" for a game being played by two teams local to different time-zones!

          It refers to the time zone of each terrestrial broadcast station's market, either the city of license [wikipedia.org] or of the nearby major city that it serves. A signal at the permitted transmission power of a radio or TV station license usually doesn't reach far outside the intended time zone. A station licensed in a city in a different time zone would descri

        • In those cases, where your plans are based on the sun, you ought to be basing your schedule on the sun.

          Most people enjoy seeing sunlight. In fact, the human body is designed to synthesize some of the vitamins it needs from sunlight. People tend to have more energy and feel more awake during daylight hours. So you can bet that most normal people want their schedule based around the sun. Since sunlight is a local phenomenon, the times that people schedule things are obviously going to be based on some local definition.

          You can easily start work an hour after sunrise. If the sun matters to you, you'll skip the days when it's raining, or you'll wait for the rain to pass.

          "we leave at first-light" means when you can see, not when the sun is blocked by clouds.

          Say what you actually mean.

          But the primary function of time today, is not to synchronize activity with the sun. Today, it's to synchronize human activity with other human activity, often across great distances.

          Says you. But again, most people want time to be based on useful hours of sunlight. And

        • Re: (Score:2)

          by bws111 ( 1216812 )

          Those are some pretty pathetic examples. First of all, the vast majority of HUMAN use of time is in the persons own local time. Yes, people do communicate with each other over long distances, but those interactions are certainly a very small percentage of the usage of time.

          Wouldn't it be nice if we had the same noon? No, it would not. No matter where you are in the world, 'noon' (if whatever language) has the same connotations: the sun is at its highest, most people are up and about, many people are get

      • Because the primary function of time since the dawn of civilization has been to allow human activity to synchronize with the position of the sun, from planting seasons to night watches.

        Most human beings have lives that are affected by sunlight.

        The sunlight will happen at its own schedule whether or not we set our watches and calendars by it. We use Daylight Saving Time in large part precisely because the standard definition (noon = sun at highest point) doesn't actually work well for many of us. I don't really care if daylight starts at 7am or 7pm and it won't change fast enough within my lifetime for it to affect me much.

      • Why should I care where the sun is, where the moon is, where the earth is, with respect to time?

        Because the primary function of time since the dawn of civilization has been to allow human activity to synchronize with the position of the sun, from planting seasons to night watches.

        If it's winter, I can start work at 9, I can start at 10, I can start an hour after sunrise.

        If you never leave the server room, perhaps. Most human beings have lives that are affected by sunlight. At the very least commuting in light or dark matters. Construction, farming, and many other jobs are deeply affected by daylight conditions. And some of us actually just like to go and play in the big blue room while it's blue. (Try it sometime!)

        Okay, so let's say time drifts 6 hours. What was 6 am now occurs at noon.

        That just means that rather than working 900 to 1700, you now work 1500 to 2300. You'd still be working the same hours relative to the sun. The only difference is what direction the little hand on the clock points (if analog clocks even still exist at that point).

        • Re: (Score:2)

          by bws111 ( 1216812 )

          That works fine if you are the only person involved. In real life, most of us interact with other people, businesses, etc. And that requires synchronized time.

          So if we use your idea of not changing the clocks, but changing what time we do things, that means that every time there is an adjustment (to keep us synced up with the sun), EVERY SINGLE REFERENCE to time must change. Businesses are open different hours, meetings happen at different times, appointments occur at different times, etc. Not only that

    • Re: (Score:2)

      by arth1 ( 260657 )

      Last I checked, we have perfectly wonderful time-keeping and gps devices these days. So ocean ships and submarines no longer need a sextant and a chronometer to figure out when and where they are.

      So here's my petition. I'd like time to always move forward, and the same rate of 1 second per second.

      The concept of measuring time but not have a clock is not new, and it falls apart due to time being a local phenomenon, and a local phenomenon only.
      If the gps satellite just counts time passing, it drifts away from the seconds you count. They're not the same. In fact, the gps system is adjusted precisely to compensate for time passing at different rates due to acceleration.
      Everyone's time passes at a slightly different and non-constant rate. There's a measurable difference in how fast time passes in Reykj

      • A very good point, actually.

        So then let's pick a clock; one that can govern us all. It doesn't matter which clock, as long as it's the same clock. So let's go either with one sitting an the north pole, or one sitting on the sun. Home world or home star. I don't really care which at this point.

        • So then let's pick a clock; one that can govern us all.

          Oh you mean this one?

          One Clock to rule them all, One Clock to find them, One Clock to bring them all, and in the darkness bind them.

    • Actually, the thing that drives me batty is not so much whether or not time noon is synced with solar noon or if the sun rises or sets at 5, 6, or 7. Between managing servers on various continents and syncing phone meetings with co-workers scattered all over the place, I've come to the conclusion that daylight savings time, time zones, and the am/pm thing are all the work of the devil, and they should be abolished and we should all use GMT.

      I don't see why it matters a whit whether I start work at 8:30am, 0

      • Re: (Score:2)

        by bws111 ( 1216812 )

        No, having everything use GMT does NOT make it easier to coordinate people. While you may be starting work at 1630GMT, I am leaving then. How did it get any easier to coordinate? The only thing it would do is make it easier to COMMUNICATE times across boundaries, and the number of times that happens without a computer involved is a very, very tiny fraction of all of the other uses of time.

        And you are completely disregarding the cultural uses of time. If I say 5PM (or 1700) to you, what image does that ev

    • Re: (Score:2)

      by sjames ( 1099 )

      Part of it is because there's a million pointy haired morons out there who will throw a temper tantrum if you're not there at exactly 9:00 A.M. and they don't give a damn if the sun won't rise for another 9 hours.

      Moving right along to your 1 sec = 1 sec desires, what do you plan to do when your clock has drifted from the standard? You can either jump (against your express wishes) or slightly change the length of a second according to your clock until you come back into agreement (also against your express w

  • Hold up, slow down.... Wait just a second...

    We are going to debate this for weeks? The solution is clear and the question is easy... How close do we need to be to the astronomical time? Once you answer that, we all know what to do.

    • How close do we need to be to the astronomical time?

      My argument would be that we don't. Who cares if the seasons shift to different months over a few hundred years? It's not going to be important within the lifetime of anyone reading this. If it snows in June instead of December I just don't see that as an actual problem. Pick an epoch [wikipedia.org] and count from there. No need to keep the seasons matched to the calendar for eternity. In fact if we leave Earth, doing that will quickly become highly impractical.

    • The solution is clear and the question is easy...

      Obviously we gotta speed up the earth's rotation so it keeps up with our clocks.

    • Re: (Score:2)

      by Kythe ( 4779 )
      The main reason for aligning clocks with the sun is for navigational methods that aren't really used anymore.

      At this point, it makes much more sense to have a fundamental time reference that provides 60 seconds to a minute, period, and if you really want to translate to your local sun-referenced time, make use of translation tables.

      Right now, we muck with the fundamental reference. That's the basic issue that needs solving.

      • The main reason for aligning clocks with the sun is for navigational methods that aren't really used anymore.

        You mean like the human biological tendency to be active at certain hours before and after peak outdoor light?

        At this point, it makes much more sense to have a fundamental time reference that provides 60 seconds to a minute, period, and if you really want to translate to your local sun-referenced time, make use of translation tables.

        Theoretically this "fundamental time reference" is TAI (International Atomic Time [wikipedia.org], and the leap second history acts as the "translation tables" you describe between TAI and UTC. The problem is that UNIX adopted UTC as the basis for its timestamps.

    • Re: (Score:3)

      by msauve ( 701917 )
      "How close do we need to be to the astronomical time?"

      For UTC, within 1 second. That's what it was created for, to follow Sol, just like the other UTx timescales.

      For those who don't care, there are timescales which don't have leap seconds - TAI, GPS, etc. Use them instead of trying to redefine UTC to be completely decoupled from its intended purpose.

      This issue isn't leap seconds, it's lazy or stupid programmers or committees who don't or won't understand how UTC works.
  • It must either deal with it or be designed to fail gracefully. It's not like we have a choice.

  • If you can't deal, don't use UTC (Score:4, Insightful)

    by oneiros27 ( 46144 ) on Friday October 30, 2015 @10:36AM (#50832757) Homepage

    There are plenty of systems for time that *don't* involve leap seconds.

    If your system's too crappy to be able to deal with leap seconds or you don't have a way to update them, use TAI or GPS time.

    Don't screw with the definition of UTC just because you can't handle the complexities of it. It's not like someone's forcing you to use UTC, UT1R, or one of the other UT systems that are specifically intended to deal with issues of local noon.

    (disclaimer: I work for a group that deals with solar observations*)

    * and even one of them almost screwed the pooch and didn't distribute the update for the June/July 2015 leap second until 3 days before it happened ... and of course it was compiled in (for speed, they claimed**) rather than be an external file.

    ** if it really was for speed, then they need to flip their giant if/then structure so it starts in the present and walks backwards in time, rather than how they're doing it now where it runs dozens of tests that will always fail for a spacecraft that wasn't launched 'til 2010.

    • Around here there is "River Time." It has considerable flexibility built in. For example, 1:00 p.m. can be read as, "sometime after lunch today, or maybe tomorrow morning." It works for most things, but probably not for launching that next probe to Europa.

  • I don't know what it is that drives a certain set of computer nerds to demand the rest of the world change their practices and deal with the cascading list of effects, just because said nerds find something inconvenient or annoying.

    This is so much like the "everyone needs to switch their lives to UTC" droning... it's just not funny anymore.

  • The addition to UTC is supposed to keep atomic time aligned with Earth's rotation, but past leap seconds have caused server crashes

    So some day it'll be dark at noon, but our buggy software will still function.

  • I appreciate that its necessary to adjust the clocks to celestial bodies as appropriate. But why do it all at once, and suffer from the aftereffects.

    When a leap second WOULD have been declared, have the NTP stratum-1 servers bias things a bit until the -1 and astro-time match, and let the world catch up over the next few hours/days (one tiny increment at a time).

    No software glitches. Tiny differences between systems, but we always have those anyway.

    Astronomer's and other's that really care, use -0 time adju

  • Eh? (Score:3)

    by wonkey_monkey ( 2592601 ) on Friday October 30, 2015 @10:59AM (#50832979) Homepage

    The days of 61-second minutes may be coming to an end

    Wait... are they getting rid of days, seconds, or minutes?

  • Leap-Seconds Existed More Than 45 Years Ago (Score:5, Insightful)

    by DERoss ( 1919496 ) on Friday October 30, 2015 @11:01AM (#50833005)

    Leap-seconds were properly handled in computer software before most of today's software engineers and programmers were born.

    Back in 1969, I started working on a software system that already handled leap-seconds quite smoothly. At that time, keeping UTC aligned with the rotation of the earth involved introducing fractional seconds and also having UTC seconds NOT the same duration as atomic seconds (TAI). In 1972, this was simplified by having UTC seconds exactly the same duration as TAI seconds and (after an initial fractional leap) introducing only leaps that were full seconds. The software in the system on which I was working DID NOT HAVE TO CHANGE!!.

    Internally, the system on which I was working -- which evolved and continued in use to operate military space satellites for over 20 years -- kept all time in TAI, which never has leap-seconds. A relatively small routine converted in either direction between UTC for displays and TAI for internal time. Another small routine converted from UTC to UT! to sidereal time, the latter more closely reflecting the rotation of the earth, which is gradually slowing and also has predictable periodic fluctuations. The purpose of all this was that we needed to know very accurately the spot on the rotating earth directly under the orbiting space satellite. The position of the satellite was known in TAI while the surface of the earth was rotating very closely to sidereal time.

    Also note that the network time protocol (NTP) also accounts for leap-seconds and has done so for decades.

    I can only conclude that the current attempt to do away with leap-seconds is a result of lazy software "professionals" trying to shift blame for their ignorance about leap-seconds.

  • Make water boil at 200F and make pi be 3 again!

  • They want to shift the problem to someone else. (Score:3)

    by NeoMorphy ( 576507 ) on Friday October 30, 2015 @11:17AM (#50833137)

    Incompetent people like to shift problems to someone else. They're already trying to shift problems like "national debt", pollution,and "climate change" to the future generations and now they want to shift another problem to a future generation.

    I would prefer better coding and testing standards to be the norm. At the moment, every time a problem occurs because of a "leap second" it's noticed and fixed with a reminder that this is something to be watched and tested for. I would like to think that handling it would become part of the standard QA procedures, actually it should have already been part of QA, it's not new, this has been happening for over 40 years!

    If they think a "leap second" is a big deal then a "leap minute" or "leap hour" is going to really cause problems. They'll have longer periods of time for more bugs to accumulate and when they happen everything will have problems because either they'll fail or something they depend on will fail.

    • Re: (Score:2)

      by amorsen ( 7485 )

      If they think a "leap second" is a big deal then a "leap minute" or "leap hour" is going to really cause problems. They'll have longer periods of time for more bugs to accumulate and when they happen everything will have problems because either they'll fail or something they depend on will fail.

      Leap minutes or leap hours would be handled by the existing time zone handling, not by messing with the length of a second. That code is well tested and very robust.

      Warnings about leap minutes or leap hours could be made years in advance, leaving plenty of time to update the files on even the most remote systems.

      And yes, technically leap seconds should be handled via the time zone system as well. GNU even distributes a set of zone files for that purpose, the ones that start with "right" instead of "posix".

      • Leap minutes or leap hours would be handled by the existing time zone handling, not by messing with the length of a second. That code is well tested and very robust.

        I can see that working, but I'm not sold on the "well tested and very robust".

        If Apple iphones are working properly with time zones(daylight savings), that's only within the past two years. Can MS Windows use time zones properly or do you still have to set the hardware clock to the current time in the current time zone? Do they still prompt if it's okay to change to/from daylight savings if the computer was turned off during the time change? Java uses their own time zone files for some reason, no idea why t

Slashdot Top Deals

Genius is ten percent inspiration and fifty percent capital gains.

Close