5 ms·

GPS will broadcast a 0 second leap second in 128 days. This will cause no issues

57 points by edward 5y ago

maxclark 5y ago
Booking a vacation for 126 days now.
sebzim4500 5y ago
Might be a dumb question, but these leap seconds seem like they cause way more hassle than they are worth. Why don't we just stop adding them?
- paxys 5y ago
  They cause a hassle but are required. The Earth's rotation isn't perfectly constant, so without any adjustment we would keep drifting away from solar time.
  - neckardt 5y ago
    What's the problem with slowly drifting away from solar time? If 9:00am became 9:10am by the time I'm 100 years old I don't think I'd encounter any difficulties. Who requires this level of accuracy?
    - beerandt 5y ago
      Because then you'd still need an almanac of the drift in determining celestial location/navigation. It's easier to just keep high noon at the Greenwich observatory as the defining datum, since most worldwide coordinates ultimately reference back to it, being 0deg longitude. Ultimately, either time or location would need to be adjusted, and it's easier to do time. Plus it's consistent with what's been done historically.
    - gh02t 5y ago
      There isn't a huge problem with changing it, there are people who want to do exactly that and do something else instead. The prominent alternatives that I know of still do something to keep time tied to the mean solar day, though, and changing time standards can be a complicated process so it's likely to take a while. https://en.wikipedia.org/wiki/Leap_second#International_proposals_for_elimination_of_leap_seconds https://en.wikipedia.org/wiki/Leap_second#International_prop...
    - IfOnlyYouKnew 5y ago
      It’s sorta like asking why we don’t fix pi at 3.1, even if the scale may (initially) be smaller. Or get rid of time zones: It’s sacrificing truth for the convenience of about a dozen people in IT.
      - tablespoon 5y ago
        > It’s sacrificing truth for the convenience of about a dozen people in IT. But those dozen IT people think the trade off is really worth it (for them)!
      - Gigachad 5y ago
        This is exactly the kind of thing that is often done. Some software will just treat all months as having 30 days because it simplifies logic massively and doesn't cause that much of an issue.
      - MiddleEndian 5y ago
        >It’s sacrificing truth for the convenience of about a dozen people in IT. And this kind of thing can never be undone. See: NTSC "60" Hz actually being 59.94 Hz due to the transition between black and white and color TV. Monitors today still have this lasting effect for consistency's sake.
  - himinlomax 5y ago
    They are not required when using TAI. The only sensible way to count time is with TAI. UTC and its leap seconds should only be used for display/parsing, not for counting time. That people do otherwise is rage inducing.
    - nextaccountic 5y ago
      YEP! no timestamp should EVER be in UTC.
    - user-the-name 5y ago
      A time expressed in TAI that is in the future has no conversion to human-readable time. That is not a very useful piece of data for many, many use cases.
      - d110af5ccf 5y ago
        > TAI that is in the future has no conversion to human-readable time Doesn't it convert to within some margin for error? Checking Wikipedia, I see that the delta between TAI and Unix time has only drifted 27 seconds since 1972. That should be more than sufficient for your average mundane human readable purpose.
- beerandt 5y ago
  For navigation especially, these leap seconds are important so that celestial bodies rise/set/transit overhead at the expected times when calculating longitude. Lots of critical military devices still use star based navigation, and likely even more will in the future, since it's become obvious we can't rely on NAVSTAR GPS to be working if we go to war.
  - toomuchtodo 5y ago
    > Lots of critical military devices still use star based navigation, and likely even more will in the future, since it's become obvious we can't rely on NAVSTAR GPS to be working if we go to war. I pine for a commercial/hobbyist grade celestial navigation system (point CCD at sky, get position). If anyone has any recommendations or pointers, would love them.
    - kadoban 5y ago
      You still need an accurate clock even if you can use a view of the sky, right? Not sure the best way that could work. Could accept optional updates to time via GPS? Would this potentially work during the day, or do you need to be able to see stars? If you can see the Sun I guess that should be good enough, if the sensor can even handle that without clipping to hell? Do you also have to be able to accurately measure angle to the horizon too? I'm not all that familiar with celestial navigation in practice.
      - toomuchtodo 5y ago
        So most of my research is historical (military hardware [1]) and amateur. Building my own attempt has been on my TODO list for sometime. Assume I would use something like a CSAC (chip scale atomic clock) for local high accuracy, high stability timekeeping (and for my purposes, it's probably okay to cheat and fallback to GPS to get a PPS time update occasionally). It's my understanding that existing celestial navigation systems can discern stars even during daylight, but as I mentioned, I haven't tried it yet (although when you can detect celestial markers, accuracy can be as good as ~20 meters with a fix provided in sub 30 seconds based on state of the art). To me, there's something profound about the idea of locating yourself in 3D space using light from stars light years away. GPS is great, but the universe is inherently providing beacons (not just stars, but also pulsars [2]) for positioning and guidance. That's very cool! [1] https://timeandnavigation.si.edu/multimedia-asset/nortronics-nas-14v2-astroinertial-navigation-system https://timeandnavigation.si.edu/multimedia-asset/nortronics... (Nortronics NAS-14V2 Astroinertial Navigation System: Mounted behind the SR-71’s cockpit, this unit, affectionately known as “R2-D2,” computed navigational fixes using stars sighted through the lens in the top of the unit. These fixes were used to update the inertial navigation system and provided course guidance with an accuracy of at least 90 meters (300 feet). Some current aircraft and missile systems use improved versions as a backup to GPS.") [2] https://directory.eoportal.org/web/eoportal/satellite-missions/content/-/article/iss-utilization-nicer-sexta-1 https://directory.eoportal.org/web/eoportal/satellite-missio... (ISS Utilization: NICER/SEXTANT) (I have not acquired nor reversed engineering any military grade celestial navigation equipment or systems, please don't sic ITAR on me)
Nexxxeh 5y ago
Can someone ELI5? The Tweet and the "This will cause no issues" feels tongue-in-cheek and the gif suggests there will most likely be issues.
- heythere22 5y ago
  As far as I understand it, the GPS time will stop for 1 second. This means that between ex. 12:00:00 and 12:00:00' there is a wall clock difference of 1 second. The first issue has already been found: https://twitter.com/uputronics/status/1418990637299519493 https://twitter.com/uputronics/status/1418990637299519493
  - user-the-name 5y ago
    No, GPS time will not stop, and that is the issue. What you describe is a regular leap second, but now for some reason GPS is broadcasting that it will have a leap second that doesn't actually do anything.
    - beerandt 5y ago
      GPS specs a specific window (the broadcast message bit positions) in the ephemeris for specifying leap seconds, so that data window has to be filled with a value, even if it's zero. The issue is that only certain defined gps weeks use those bits for that purpose (when to actually apply the upcoming leap second), and it doesn't happen that often. But anyone who assumed that an upcoming leap second message implies a non-zero value hasn't done their basic homework. It's a regularly recurring message, not only done when required.
- kaydub 5y ago
  > This will cause no issues It will most certainly cause some issues. I worked somewhere that sold a software appliance back in the day. This software appliance did a bunch of ETL and ran analytics processes. We had a leap second that caused all the ETL jobs to stop working. 400 some appliances in different data centers that we had some connectivity through a VPN. It was not a fun experience but it has always kept leap seconds and time problems in the front of my mind.
swiley 5y ago
I thought GPS time didn't have leap seconds?
- vermilingua 5y ago
  GPS time needs many leap seconds, as satellites experience a slower passage of time due to relativity.
- detaro 5y ago
  And receivers on earth (or at least the humans reading their output) want UTC, so GPS needs to tell them when to add a leap second.
- imglorp 5y ago
  It does not, but UTC does. The GPS broadcast contains GPS time and enough information for receivers to obtain UTC from GPS. > Information in subframe 4 of the NAV message includes the relationship between GPS time and UTC, and it also notes future scheduled leap seconds. In this area, subframe 4 can accommodate 8 bits, 255 leap seconds, which should suffice until about 2330. https://www.e-education.psu.edu/geog862/node/1736 https://www.e-education.psu.edu/geog862/node/1736
offmycloud 5y ago
I noticed that my LeoNTP [1] GPS time server is counting down to the non-existent leap second near the end of November. I hope that it doesn't advertise this as an upcoming leap second to downstream NTP clients just before the event. 1. http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=120&products_id=272 http://www.leobodnar.com/shop/index.php?main_page=product_in...
- ArchOversight 5y ago
  In this tweet it says it will require a firmware update: https://twitter.com/uputronics/status/1418611804004048901 https://twitter.com/uputronics/status/1418611804004048901
tvb 5y ago
Don't worry. This happened once before in 2003 [1]. UTC has provisions for positive or negative leap seconds; that works fine. GPS runs without the hassle of leap seconds; that works fine too. GPS users often want to know UTC, so GPS also broadcasts the difference between GPS time and UTC; this works fine. All of this is in the GPS spec; almost all GPS receiver firmware gets it right. But there is a weird edge case that is hard to test. Specifically if there has been no leap second for 256 weeks (1792 days, ~5 years) inadequately tested GPS receiver firmware could mess up. It happened to one make/model GPS receiver in 2003. [1] It could happen again later this year, in 2021. The math is fun. The most recent leap second was 2016-12-31 (MJD 57753). 8 bits or 256 weeks later(1792 days, not to be confused with Ramanujan's taxi number 1729) will be 2021-11-27 (MJD 59545). So shortly before, or on, or after that date it is possible a faulty GPS receiver will misrepresent a leap second or miscalculate UTC. GPS positioning and navigation is likely completely unaffected (because it avoids leap seconds entirely). [1] http://leapsecond.com/notes/leapsec256.htm http://leapsecond.com/notes/leapsec256.htm
adminscoffee 5y ago
this shouldn't be mentioned, now people are gonna freak out even if it's not an issue lol
pyuser583 5y ago
I once wrote a unit test that always failed on the 31st day of the month.

57 points by edward 5y ago

Booking a vacation for 126 days now.

Might be a dumb question, but these leap seconds seem like they cause way more hassle than they are worth. Why don't we just stop adding them?

paxys 5y ago
They cause a hassle but are required. The Earth's rotation isn't perfectly constant, so without any adjustment we would keep drifting away from solar time.
- neckardt 5y ago
  What's the problem with slowly drifting away from solar time? If 9:00am became 9:10am by the time I'm 100 years old I don't think I'd encounter any difficulties. Who requires this level of accuracy?
  - beerandt 5y ago
    Because then you'd still need an almanac of the drift in determining celestial location/navigation. It's easier to just keep high noon at the Greenwich observatory as the defining datum, since most worldwide coordinates ultimately reference back to it, being 0deg longitude. Ultimately, either time or location would need to be adjusted, and it's easier to do time. Plus it's consistent with what's been done historically.
  - gh02t 5y ago
    There isn't a huge problem with changing it, there are people who want to do exactly that and do something else instead. The prominent alternatives that I know of still do something to keep time tied to the mean solar day, though, and changing time standards can be a complicated process so it's likely to take a while. https://en.wikipedia.org/wiki/Leap_second#International_proposals_for_elimination_of_leap_seconds https://en.wikipedia.org/wiki/Leap_second#International_prop...
  - IfOnlyYouKnew 5y ago
    It’s sorta like asking why we don’t fix pi at 3.1, even if the scale may (initially) be smaller. Or get rid of time zones: It’s sacrificing truth for the convenience of about a dozen people in IT.
    - tablespoon 5y ago
      > It’s sacrificing truth for the convenience of about a dozen people in IT. But those dozen IT people think the trade off is really worth it (for them)!
    - Gigachad 5y ago
      This is exactly the kind of thing that is often done. Some software will just treat all months as having 30 days because it simplifies logic massively and doesn't cause that much of an issue.
    - MiddleEndian 5y ago
      >It’s sacrificing truth for the convenience of about a dozen people in IT. And this kind of thing can never be undone. See: NTSC "60" Hz actually being 59.94 Hz due to the transition between black and white and color TV. Monitors today still have this lasting effect for consistency's sake.
- himinlomax 5y ago
  They are not required when using TAI. The only sensible way to count time is with TAI. UTC and its leap seconds should only be used for display/parsing, not for counting time. That people do otherwise is rage inducing.
  - nextaccountic 5y ago
    YEP! no timestamp should EVER be in UTC.
  - user-the-name 5y ago
    A time expressed in TAI that is in the future has no conversion to human-readable time. That is not a very useful piece of data for many, many use cases.
    - d110af5ccf 5y ago
      > TAI that is in the future has no conversion to human-readable time Doesn't it convert to within some margin for error? Checking Wikipedia, I see that the delta between TAI and Unix time has only drifted 27 seconds since 1972. That should be more than sufficient for your average mundane human readable purpose.
beerandt 5y ago
For navigation especially, these leap seconds are important so that celestial bodies rise/set/transit overhead at the expected times when calculating longitude. Lots of critical military devices still use star based navigation, and likely even more will in the future, since it's become obvious we can't rely on NAVSTAR GPS to be working if we go to war.
- toomuchtodo 5y ago
  > Lots of critical military devices still use star based navigation, and likely even more will in the future, since it's become obvious we can't rely on NAVSTAR GPS to be working if we go to war. I pine for a commercial/hobbyist grade celestial navigation system (point CCD at sky, get position). If anyone has any recommendations or pointers, would love them.
  - kadoban 5y ago
    You still need an accurate clock even if you can use a view of the sky, right? Not sure the best way that could work. Could accept optional updates to time via GPS? Would this potentially work during the day, or do you need to be able to see stars? If you can see the Sun I guess that should be good enough, if the sensor can even handle that without clipping to hell? Do you also have to be able to accurately measure angle to the horizon too? I'm not all that familiar with celestial navigation in practice.
    - toomuchtodo 5y ago
      So most of my research is historical (military hardware [1]) and amateur. Building my own attempt has been on my TODO list for sometime. Assume I would use something like a CSAC (chip scale atomic clock) for local high accuracy, high stability timekeeping (and for my purposes, it's probably okay to cheat and fallback to GPS to get a PPS time update occasionally). It's my understanding that existing celestial navigation systems can discern stars even during daylight, but as I mentioned, I haven't tried it yet (although when you can detect celestial markers, accuracy can be as good as ~20 meters with a fix provided in sub 30 seconds based on state of the art). To me, there's something profound about the idea of locating yourself in 3D space using light from stars light years away. GPS is great, but the universe is inherently providing beacons (not just stars, but also pulsars [2]) for positioning and guidance. That's very cool! [1] https://timeandnavigation.si.edu/multimedia-asset/nortronics-nas-14v2-astroinertial-navigation-system https://timeandnavigation.si.edu/multimedia-asset/nortronics... (Nortronics NAS-14V2 Astroinertial Navigation System: Mounted behind the SR-71’s cockpit, this unit, affectionately known as “R2-D2,” computed navigational fixes using stars sighted through the lens in the top of the unit. These fixes were used to update the inertial navigation system and provided course guidance with an accuracy of at least 90 meters (300 feet). Some current aircraft and missile systems use improved versions as a backup to GPS.") [2] https://directory.eoportal.org/web/eoportal/satellite-missions/content/-/article/iss-utilization-nicer-sexta-1 https://directory.eoportal.org/web/eoportal/satellite-missio... (ISS Utilization: NICER/SEXTANT) (I have not acquired nor reversed engineering any military grade celestial navigation equipment or systems, please don't sic ITAR on me)

Nexxxeh 5y ago

Can someone ELI5? The Tweet and the "This will cause no issues" feels tongue-in-cheek and the gif suggests there will most likely be issues.

heythere22 5y ago
As far as I understand it, the GPS time will stop for 1 second. This means that between ex. 12:00:00 and 12:00:00' there is a wall clock difference of 1 second. The first issue has already been found: https://twitter.com/uputronics/status/1418990637299519493 https://twitter.com/uputronics/status/1418990637299519493
- user-the-name 5y ago
  No, GPS time will not stop, and that is the issue. What you describe is a regular leap second, but now for some reason GPS is broadcasting that it will have a leap second that doesn't actually do anything.
  - beerandt 5y ago
    GPS specs a specific window (the broadcast message bit positions) in the ephemeris for specifying leap seconds, so that data window has to be filled with a value, even if it's zero. The issue is that only certain defined gps weeks use those bits for that purpose (when to actually apply the upcoming leap second), and it doesn't happen that often. But anyone who assumed that an upcoming leap second message implies a non-zero value hasn't done their basic homework. It's a regularly recurring message, not only done when required.
kaydub 5y ago
> This will cause no issues It will most certainly cause some issues. I worked somewhere that sold a software appliance back in the day. This software appliance did a bunch of ETL and ran analytics processes. We had a leap second that caused all the ETL jobs to stop working. 400 some appliances in different data centers that we had some connectivity through a VPN. It was not a fun experience but it has always kept leap seconds and time problems in the front of my mind.

swiley 5y ago

I thought GPS time didn't have leap seconds?

vermilingua 5y ago
GPS time needs many leap seconds, as satellites experience a slower passage of time due to relativity.
detaro 5y ago
And receivers on earth (or at least the humans reading their output) want UTC, so GPS needs to tell them when to add a leap second.
imglorp 5y ago
It does not, but UTC does. The GPS broadcast contains GPS time and enough information for receivers to obtain UTC from GPS. > Information in subframe 4 of the NAV message includes the relationship between GPS time and UTC, and it also notes future scheduled leap seconds. In this area, subframe 4 can accommodate 8 bits, 255 leap seconds, which should suffice until about 2330. https://www.e-education.psu.edu/geog862/node/1736 https://www.e-education.psu.edu/geog862/node/1736

offmycloud 5y ago

I noticed that my LeoNTP [1] GPS time server is counting down to the non-existent leap second near the end of November. I hope that it doesn't advertise this as an upcoming leap second to downstream NTP clients just before the event. 1. http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=120&products_id=272 http://www.leobodnar.com/shop/index.php?main_page=product_in...

ArchOversight 5y ago
In this tweet it says it will require a firmware update: https://twitter.com/uputronics/status/1418611804004048901 https://twitter.com/uputronics/status/1418611804004048901

tvb 5y ago

Don't worry. This happened once before in 2003 [1]. UTC has provisions for positive or negative leap seconds; that works fine. GPS runs without the hassle of leap seconds; that works fine too. GPS users often want to know UTC, so GPS also broadcasts the difference between GPS time and UTC; this works fine. All of this is in the GPS spec; almost all GPS receiver firmware gets it right. But there is a weird edge case that is hard to test. Specifically if there has been no leap second for 256 weeks (1792 days, ~5 years) inadequately tested GPS receiver firmware could mess up. It happened to one make/model GPS receiver in 2003. [1] It could happen again later this year, in 2021. The math is fun. The most recent leap second was 2016-12-31 (MJD 57753). 8 bits or 256 weeks later(1792 days, not to be confused with Ramanujan's taxi number 1729) will be 2021-11-27 (MJD 59545). So shortly before, or on, or after that date it is possible a faulty GPS receiver will misrepresent a leap second or miscalculate UTC. GPS positioning and navigation is likely completely unaffected (because it avoids leap seconds entirely). [1] http://leapsecond.com/notes/leapsec256.htm http://leapsecond.com/notes/leapsec256.htm

adminscoffee 5y ago

this shouldn't be mentioned, now people are gonna freak out even if it's not an issue lol

pyuser583 5y ago

I once wrote a unit test that always failed on the 31st day of the month.