Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Science

The World Votes to Stop Adding 'Leap Seconds' to Official Clocks (nature.com) 106

Posted by EditorDavid from the second-changes dept.
The Guardian notes that "While leap seconds pass by unnoticed for most people, they can cause problems for a range of systems that require an exact, uninterrupted flow of time, such as satellite navigation, software, telecommunication, trade and even space travel."

So now Nature magazine reports that "The practice of adding 'leap seconds' to official clocks to keep them in sync with Earth's rotation will be put on hold from 2035, the world's foremost metrology body has decided." The decision was made by representatives from governments worldwide at the General Conference on Weights and Measures (CGPM) outside Paris on 18 November. It means that from 2035, or possibly earlier, astronomical time (known as UT1) will be allowed to diverge by more than one second from coordinated universal time (UTC), which is based on the steady tick of atomic clocks. Since 1972, whenever the two time systems have drifted apart by more than 0.9 seconds, a leap second has been added....

Facebook's parent company, Meta, and Google are among the tech companies that have called for leap seconds to be scrapped. The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute. But it plans to consult with other international organizations and decide by 2026 on what upper limit, if any, to put on how much they be allowed to diverge....

Although in the long term Earth's rotation slows due to the pull of the Moon, a speed-up since 2020 has also made the issue more pressing, because for the first time, a leap second might need to be removed, rather than added. UTC has only ever had to slow a beat to wait for Earth, not skip ahead to catch up with it. "It's kind of being described as a Y2K issue, because it's just something that we've never had to deal with," said Elizabeth Donley, who leads the Time and Frequency division at the National Institute of Standards and Technology, in Boulder, Colorado.
This discussion has been archived. No new comments can be posted.

The World Votes to Stop Adding 'Leap Seconds' to Official Clocks More

The World Votes to Stop Adding 'Leap Seconds' to Official Clocks

Comments Filter:

  • so we have 13 years... (Score:5, Funny)

    by acroyear ( 5882 ) <jws-slashdot@javaclientcookbook.net> on Saturday November 19, 2022 @11:48AM (#63063973) Homepage Journal

    ...to change our minds over this another 3 times before it becomes official.

    • I’m still not clear if Pluto is a planet or not.

      • Re: (Score:2, Interesting)

        by phantomfive ( 622387 )

        Pluto is considered a planet by all. A dwarf planet is a planet.

        The only question is whether we should teach it to kids in elementary school along with the other planets. And frankly that's not a practical question. Do whatever you want. For me, I would teach them that it's a planet.

        • And so are Eris, MakeMake and so on. The list of planets grows... And Ceres is a planet too?

          • And Ceres is a planet too?

            Obviously.

            Pluto has a special place in common lore because we've known about it longer. And it was discovered by an American, which is why Americans like it and Europeans hate it.

            • As a European this is the first I've ever heard about us supposed to hate Pluto. When was that decided? We even have Pluto as part of the SSS (Sweden Solar System) with both Pluto and Karon placed in Delsbo: http://www.swedensolarsystem.s... [swedensolarsystem.se] , not something we would have done if we hated it. Why does Americans so often believe that Europeans hate stuff from the US?

            • And Ceres is a planet too?

              Obviously.

              Pluto has a special place in common lore because we've known about it longer. And it was discovered by an American, which is why Americans like it and Europeans hate it.

              Actually, Ceres was discovered in 1801 and Pluto in 1930.

  • Mostly seems to find broken software (Score:5, Insightful)

    by Burdell ( 228580 ) on Saturday November 19, 2022 @12:00PM (#63064009)

    Leap seconds aren't THAT hard to handle, but software keeps finding new and exciting ways to break.

    A problem with letting the time systems diverge is that trying to bring them back into sync later would be significantly more difficult. While individual leap seconds are documented and handled in the various relevant protocols, a greater step is not. You would instead have to have some kind of weird jump (similar to September 1752 in the UK/colonies, other dates in other areas). I guess they could just add a leap second at every scheduled opportunity until they sync, but that'd be annoying.

    • Re: (Score:2)

      by piojo ( 995934 )

      According to the summary, a negative leap second is also not a handled case, and the need for that is coming up. So our choices are to let time get out of sync in one direction and correct it in the other direction, or to let it get out of sync period.

      • But it's ALWAYS out of sync. We just adjust when it's a whole number we can humanly process. So let it drift backward and then eventually drift forward to the 0.9 and adjust like normal. What is being proposed is to just keep kicking down to later generations to solve a bigger problem with a bigger impact. It's the usual selfish "will be dead, not my problem" mentality.

        • Will it really be that hard to add a leap minute when it's needed? Like 60 times harder than adding a leap second?

          • Yes, it actually will be. It's so far off like the Y2K that programs will not be tested for its failure point. Those programs will make it further into the overall programming landscape and there will be many failure points across a wider reach far into the future.

            It's better to have the second as we humans can comprehend it and thus can accommodate it in our programs. And since it occurs more often, we will be forced to test for it. Or worst case, it fails early enough to minimize the reach and damage.

      • According to the summary, a negative leap second is also not a handled case, and the need for that is coming up. So our choices are to let time get out of sync in one direction and correct it in the other direction, or to let it get out of sync period.

        BTW, how is it that the Earth's rotation has speeded up???

        • Re: (Score:2, Informative)

          by Anonymous Coward

          Earthquakes and eruptions can shift enough of the earths material up/down to noticeably change the planets angular momentum, and this change increases/decreases the rotation rate. Analogies to ice skaters left to other posters.

      • >> a negative leap second is also not a handled case
        Bad software practices and lack of foresight.

    • Indeed, anyone who writes their software with the expectation that time will not change erratically will have bugs.

      Because on computers, time changes erratically for many different reasons.

      • However some things do, like GPS which needs to be nanosecond accurate.

        Having to add somewhat random leap seconds to algorithms could be very tricky. We are not talking about just changing a computer's clock, but software that depends on accurate time.

        Setting time backwards is very problematic because you end up with two real seconds that have the same clock tick time. This is already a problem with daylight saving, there are some UTC times that correspond to two different local times.

        And just setting the

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      Leap seconds are a headache. It's not so bad if your application can be updated when they decide to add a new one. If it's embedded, or out if support, or updates need extensive qualification...

      Say you have a process that needs to run for exactly 5 hours. A leap second happens in the middle of it. You need extra code to account for that, and it needs to know when the leap second happened. You can't predict leap seconds.

      Same for calculating times in the past. You need a table of when the leap seconds happene

      • Leap seconds only matter for civil time, which generally only matters for external interactions. Code that just needs to run for x time can ignore all that and use duration since epoch.

        • Re: (Score:2)

          by AmiMoJo ( 196126 )

          It depends how the user wants it programmed. Say they want a task to run from 10 PM to 2 AM. Every now and then that task will randomly run for an extra second. If you enforce the run time at 14,400 seconds then every now and then it will randomly finish 1 second early, and the customer might notice the missing data.

          • It depends how the user wants it programmed. Say they want a task to run from 10 PM to 2 AM. Every now and then that task will randomly run for an extra second. If you enforce the run time at 14,400 seconds then every now and then it will randomly finish 1 second early, and the customer might notice the missing data.

            It's worse than that due to daylight saving time. "It depends on how the user wants it programmed" is exactly correct. If the requirement is to collect 4 hours of data starting at 10 PM, you use CLOCK_MONOTONIC (or CLOCK_BOOTTIME) to collect 14,400 seconds of data no matter what the clock says. If the requirement is to collect data from 10 PM to 2 AM, you do that no matter how many seconds elapse between those two times.

            • Re: (Score:2)

              by AmiMoJo ( 196126 )

              I developed my own time handling library because I found all the off the shelf ones either didn't consider this stuff, didn't do what I needed, or were just broken.

              • I developed my own time handling library because I found all the off the shelf ones either didn't consider this stuff, didn't do what I needed, or were just broken.

                I did the same. My library is at Avoid Using POSIX time_t for Telling Time [systemeyes...rstore.com]. If your library is also licensed under the GPL, let's copy the good features of each into the other.

                • Re: (Score:2)

                  by AmiMoJo ( 196126 )

                  Unfortunately some of it is proprietary code so I have no released the most interesting parts. I am slowly getting around to doing an open source version.

                  Random aside, for embedded it would be so handy if 32,000Hz crystals were available. With 32,768Hz ones there is no good way to count milliseconds with a low power async timer.

                  • Random aside, for embedded it would be so handy if 32,000Hz crystals were available. With 32,768Hz ones there is no good way to count milliseconds with a low power async timer.

                    What's the base-2 prefix for small numbers?

                    Kilo = 1000
                    Kibi = 1024

                    Milli = 1/1000
                    Mi??? = 1/1024

                    • Re: (Score:2)

                      by AmiMoJo ( 196126 )

                      I don't use kibi, when I talk about storage kilobyte and k are always 1024. They shouldn't have tried to rename the kilobyte, and my computer doesn't have 34.359738368 gigabytes of RAM. Since Windows uses powers of two for all storage, it would have made more sense to make gibibytes the power of 10 one.

                      All they did was create confusion because JEDEC still uses powers of two and kilobytes, and RAM and various types of solid state memories are sold using kilo/mega/giga/tera byte/bit powers of 2.

                      When it comes

                    • When I'm throwing units around, it's usually at work and at work we use SI units.

                      Your disk disc drive vendor uses kilo=1,000, mega=1,000,000, giga=1,000,000,000 etc. because they get to both claim correct usage and also claim a bigger number.

                      The overlap between the base-2 and base-10 prefixes being the same did need fixing and it did need a new name as a result. The base-2 stuff is recent.

                  • Unfortunately some of it is proprietary code so I have no released the most interesting parts. I am slowly getting around to doing an open source version.

                    Feel free to take whatever you need from my library for your open source version. Let me know when you are done so I can copy your good ideas into mine.

      • This is going to complexify some use cases, but in a halfway sane system whose system clock isn't monkeyed with, it shouldn't impact yours at all.

        Best practice is don't bother converting seconds since/before epoch to or from human-readable representations (which require timezone data) until/unless you have to.

        So, providing the clock is not messed with, this pseudocode is going to work regardless of leap seconds/minutes/years/etc. It simply has no need to know or care, because its job is to run for a ce

    • While individual leap seconds are documented and handled in the various relevant protocols, a greater step is not.

      You're going about this in a very strange way. Applications and protocols should not be caring at all about how to handle a step. That should all be managed at a system level.

      At that level if you make a step, things break. If you fudge the speed of the clock, things don't. The only real question is why would you step a time if you could smear it instead? At some point there's a cutoff where it doesn't make sense. E.g. you wouldn't use smearing to correct a clock that had the wrong year set. But the differen

      • While individual leap seconds are documented and handled in the various relevant protocols, a greater step is not.

        You're going about this in a very strange way. Applications and protocols should not be caring at all about how to handle a step. That should all be managed at a system level.

        At that level if you make a step, things break. If you fudge the speed of the clock, things don't. The only real question is why would you step a time if you could smear it instead? At some point there's a cutoff where it doesn't make sense. E.g. you wouldn't use smearing to correct a clock that had the wrong year set. But the difference between 1 second and 1 minute is ultimately insignificant.

        Applications have to care about leap seconds just as they have to care about leap years and daylight saving time. Applications deal with daylight saving time by operating internally in UTC and converting to and from local time for human interactions. Applications deal with leap years by limiting themselves to the years between 1901 and 2099, then checking to see if the year number is divisible by 4.

        An application which does not wish to limit itself to the years between 1901 and 2099 can do a more complex

        • " Applications deal with leap years by limiting themselves to the years between 1901 and 2099, then checking to see if the year number is divisible by 4." ...and then they break in the year 2000.

          • " Applications deal with leap years by limiting themselves to the years between 1901 and 2099, then checking to see if the year number is divisible by 4." ...and then they break in the year 2000.

            Actually, the year 2000 was a leap year, but 1900 wasn't and 2100 won't be. The rule is that a leap year is a year that is evently divisible by 4, but if it is evenly divisible by 100 then it must also be evenly divisible by 400. See How Could the Year 2000 Be a Leap Year When 1900 Was Not? [howstuffworks.com].

    • Replace 3600 leap seconds with one leap hour...
      http://www.leapsecond.com/ [leapsecond.com]

    • Re: (Score:2)

      by amorsen ( 7485 )

      You would instead have to have some kind of weird jump (similar to September 1752 in the UK/colonies, other dates in other areas).

      Or, more appropriately, similar to November 6th 2022. Everyone seemed to survive that weird jump just fine.

  • TAI (Score:5, Insightful)

    by gwjgwj ( 727408 ) on Saturday November 19, 2022 @12:01PM (#63064015) Homepage
    Just use TAI instead of UTC internally, only convert to UTC for presentation.

    • Re:TAI (Score:5, Informative)

      by ceoyoyo ( 59147 ) on Saturday November 19, 2022 @12:40PM (#63064081)

      UTC is the time standard that we fuck around with arbitrarily. This decision just continues the tradition. People who actually need to measure consistent time will use TAI, just as they always have.

      I suppose if UTC does get far out of sync with astronomical time you'll need a different table to convert TAI to local.

      • The problem is that GPS time is often presented in UTC which isn't useful if you want to convert to another timescale reliably.

        • Re: (Score:2)

          by ceoyoyo ( 59147 )

          Get a better GPS? GPS time counts seconds since Jan 6, 1980. It's TAI plus 19 seconds.

          Actually, if your GPS isn't connected to the Internet there isn't really any way for it to show you UTC. Probably it's showing you either GPS time or GPS time plus whatever offset there was when the thing was first manufactured or maybe the last time you updated the firmware. If it is connected to the internet, any decent hardware store will sell a variety of hand cutting tools that will fix that problem for you.

          • Get a better GPS? GPS time counts seconds since Jan 6, 1980. It's TAI plus 19 seconds.

            Actually, if your GPS isn't connected to the Internet there isn't really any way for it to show you UTC. Probably it's showing you either GPS time or GPS time plus whatever offset there was when the thing was first manufactured or maybe the last time you updated the firmware. If it is connected to the internet, any decent hardware store will sell a variety of hand cutting tools that will fix that problem for you.

            Data received by a GPS receiver includes the offset between GPS time and UTC. Thus, contact with the internet is not needed to show UTC.

            • Re: (Score:2)

              by ceoyoyo ( 59147 )

              Ah, so it does. I'd definitely get a better GPS then, it seems the GPS constellation is a full participant in the grand tradition of fucking up UTC.

              https://tf.nist.gov/general/pd... [nist.gov]

              • Ah, so it does. I'd definitely get a better GPS then, it seems the GPS constellation is a full participant in the grand tradition of fucking up UTC.

                https://tf.nist.gov/general/pd... [nist.gov]

                The paper you linked to is quite interesting. I had no idea that there had been a GPS anomaly on January 25-26, 2016. The paper is mostly NIST patting itself on the back for detecting and reporting the problem, but there is some additional detail in the Air Force press release referenced in the paper. I have added this information to Wikipedia's Leap Second article, so more people will be aware of it.

    • Re:TAI (Score:5, Insightful)

      by msauve ( 701917 ) on Saturday November 19, 2022 @03:35PM (#63064443)
      Getting rid of leap seconds in UTC is simply, fucking, stupid. There are _multiple_ other timescales which don't have leap seconds, pick one if you don't want to deal with leap seconds. UTC was _specifically intended_ to closely follow astronomical time.

  • Oblig... (Score:4, Funny)

    by cellocgw ( 617879 ) <cellocgw&gmail,com> on Saturday November 19, 2022 @12:20PM (#63064049) Journal

    Does anyone really know what time it is?
    Does anyone really care?
    [trumpet solo]

  • ..."Damn you short-sighted assholes! It's drifted too fucking far now!"

  • Silly misdiagnosis of technical problem (Score:5, Interesting)

    by RightwingNutjob ( 1302813 ) on Saturday November 19, 2022 @12:26PM (#63064059)

    The fundamental problem, which should paradoxically be very familiar to computer geeks of most stripes, is that there are *two* timescales that are relevant: a monotonic timescale to be used for internal calculations and a localized timescale to be used for human-readable display and data entry.

    In the parlance of the bipm, the former is realized by TAI and the latter by UTC, aka civil time. In computer terminology, the former is what the CLOCK_MONOTONIC flag (ought to) refer to, while the latter is the localized time in whatver timezone the user happens to be in.

    Because of historical baggage, the two have been confused and conflated over the years. And because civil time is mean to place mean midnight and noon at the top and bottom of every day, the fact that civil time is not necessarily monotonic created a load of problems because people who ought to have known better used civil time instead of atomic time for internal calculations.

    The most egregious examples were, in no particular order,

    - Google stretching out the length of a second on leap second days, so that there were 86400 "seconds" per calendar day, every day, but they weren't guaranteed to be SI seconds
    - GLONASS using Moscow time (leap seconds, daylight savings, and all) as its broadcast time scale

    And I'm sure there's more.

    So now we're going to codify the stupid by declaring that civil time and atomic time are one and the same...for a hundred years at which point we may need a leap minute unless we want the clock to read 3 am at sunset at some point in the distant future.

    • Thank you for that explanation.

      THIS is why I keep coming back. I learned someting that I can understand and remember.

    • unless we want the clock to read 3 am at sunset at some point in the distant future

      As so many people want noon to happen at 13:00 ("permanent DST"), exact astronomic time doesn't seem to matter to the average person.

      • Permanent dst would be nice when you're at the eastern end of the eastern timezone and the sun sets before 5pm three months out of the year on standard time.

        The rest of the time it doesn't matter if mean noon is at clock noon or not, but consistency does. It'd be just stupid if mean noon drifted around the clock over the centuries.

    • Re: (Score:2, Interesting)

      by bhetrick ( 1812392 )

      In writing software, there are two alternatives: be able to represent reality, and be unable to represent reality. This primarily comes into play with data design. This also comes into play with time keeping. TAI's reality is uniform time. UTC's reality is tracking the rotation of the planet and civil time. And now we're screwing up one because a bunch of nitwits got the two confused, and it's easier in the short term to enable the nitwits than to educate them. This approach always works out well.

    • That's interesting - I was unaware of TAI. I mean, of course I knew about atomic clocks, but I didn't know there was an honest-to-goodness standard "time" based on them.

      Interestingly, people are fretting about leap seconds while TAI and UTC have already diverged by 37 seconds [timeanddate.com]!

  • I'm pretty sure... (Score:3)

    by nospam007 ( 722110 ) * on Saturday November 19, 2022 @02:09PM (#63064279)

    ...some senator will ask in Congress if it isn't possible to adapt Earth's rotation to the clock instead of the other way 'round.

    • ...some senator will ask in Congress if it isn't possible to adapt Earth's rotation to the clock instead of the other way 'round.

      It's more than Congresscritters that don't understand how things work. Here's Fox "News" host Bill O'Reilly in a televised debate in 2011 talking about the tides [newser.com] (emphasis mine):

      Apparently, Bill O’Reilly has never heard of the moon. In a debate Tuesday with Dave Silverman, head of the American Atheist group behind this, the Fox host tried to prove the existence of God by citing the unknowable mysteries of the tides. "I’ll tell you why [religion is] not a scam, in my opinion,” he told Silverman. “Tide goes in, tide goes out. Never a miscommunication. You can’t explain that. You can’t explain why the tide goes in."

      Silverman looked stunned. “Tide goes in, tide goes out?” he stuttered. O’Reilly pressed on. “The water, the tide—it comes in and it goes out. It always goes in, then it goes out. You can’t explain that. You can’t explain it.”

  • I'm confused (Score:3)

    by fahrbot-bot ( 874524 ) on Saturday November 19, 2022 @03:59PM (#63064485)

    Does that mean I'll be able to sleep 1s longer or have to get up 1s earlier? :-)

  • Now, I don't have to worry about this anymore.

  • So bad software engineering has won (Score:3, Informative)

    by Casandro ( 751346 ) on Saturday November 19, 2022 @05:03PM (#63064585)

    Instead of just switching computers to a leapless system and handing user in- and output similar to time zones... they try to fix buggy software that does duration calculations based on "gettimeofday" instead of clock_gettime with CLOCK_TAI or CLOCK_MONOTONIC.

    Read the man page of clock_gettime for more info.

    • Instead of just switching computers to a leapless system and handing user in- and output similar to time zones... they try to fix buggy software that does duration calculations based on "gettimeofday" instead of clock_gettime with CLOCK_TAI or CLOCK_MONOTONIC.

      Read the man page of clock_gettime for more info.

      CLOCK_BOOTTIME is better than CLOCK_MONOTONIC because it continues to count when the computer is suspended.

      • I like it when I learn new things. :)

      • Re: (Score:2)

        by butlerm ( 3112 )

        CLOCK_BOOTTIME is only better than CLOCK_MONOTONIC (on Linux) because the developers made a fundamental design error when they adopted the latter and don't want to break ABI or source compatibility.

        • CLOCK_BOOTTIME is only better than CLOCK_MONOTONIC (on Linux) because the developers made a fundamental design error when they adopted the latter and don't want to break ABI or source compatibility.

          I believe both are needed; which one you use depends on your need. If you are periodically refreshing the information on the screen, for example, use CLOCK_MONOTONIC. If you use CLOCK_BOOTTIME, all of the refreshers will run at once when the user opens the laptop's cover.

          • Re: (Score:2)

            by butlerm ( 3112 )

            I believe both are needed; which one you use depends on your need. If you are periodically refreshing the information on the screen, for example, use CLOCK_MONOTONIC. If you use CLOCK_BOOTTIME, all of the refreshers will run at once when the user opens the laptop's cover.

            I agree that both are useful, just that the Linux devs chose the wrong one to assign to CLOCK_MONOTONIC, something with which they probably agree. Of course if they did assign time since boot to CLOCK_MONOTONIC the other one would need a name like CLOCK_RUNNABLE or something.

  • And, if we ever need to go back to the current Science because the decided upon Convenience has unexpected knock on effects, the entire cost of the reversion should be calculated, trebled and paid for by Meta and Google. With interest, due in full in 30 days.

    • pffft, that's not how global standards work. This is part of the work of the overseers of the International Bureau of Weights and Measures, they define units mankind uses. You've heard of SI? they are the ones who say what SI units are.

  • Wikipedia has a comprehensive article on Leap Seconds [wikipedia.org].

  • Finally, we are rid of the clocksuckers.

  • re: "It's just something that we've never had to deal with," said Elizabeth Donley

    We dealt with skipping time on a scale of up to two weeks, all at once, not a mere skip second. That was when countries transitioned from the Julian to the Gregorian calendar.

    • In Europe, Thursday, October 4, 1582 was followed by Friday, October 15, 1582.
    • In the British Empire, Wednesday 2 September 1752 was followed by Thursday 14 September 1752.
    • Russia switched after the revolution, January 31, 1918 was followed by February
  • ...filter mention of cold and snow in Christmas music when played in the Southern Hemisphere.

Slashdot Top Deals

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Close