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.
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?
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.
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.
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.
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.
>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.
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.
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.
> 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.
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.
> 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.
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.
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... (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.")
The sun is only 1 point of reference. You would want at least 3 to know exactly where you are. I suppose a built in compass would be a 2nd.
With two points that should narrow down the position to two possible locations (with rather large uncertainty).
Edit: thinking about it further knowing north would reduce it down to 1 point. You also need to know where you are in the world to know which way magnetic north is pointing. It would be 1 very fuzzy spot.
During the day, can you see polaris? If you only have the sun as a reference you will need a 2nd reference to know where you are. Magnetic north would be easily available.
For celestial objects, The math is rather simple. It is the intersection of 2 circles. The refence between the two objects would resolve which intersection is the correct one.
For magnetic north and 1 celestial object, the math is much more complex. Magnetic declination changes depending on where you are. You have to know roughly where you are before you start using it.
You can see Polaris with the right equipment, meaning an eye adjusted to darkness, and a filter on your optics. It's always above the horizon in the Northern hemisphere, even during the day. (Same goes for the Southern cross in the Southern hemisphere.)
Polaris is important because it doesn't move, relative to the rest of the sky rotating around it.
You measure the angle from Polaris to geodetic "up" and that's the complimentary angle to your latitude. There is no complex math, just 90-x=y
If you have the time in London, and can observe the sun at its peak (solar noon) then you have longitude (after converting hours to degrees, and keeping minutes and seconds).
Or with an almanac, you can measure pretty much any known ID'd star or the sun at any time, and look up longitude from that.
Reinventing the wheel isn't needed, it's been the same process for centuries.
You'd either need to know your starting location, or have a clock synced with a known observatory, (which in combination with an overhead observation, is just another way to determine your approximate starting location).
You don't measure angle to the horizon, but angle from gravitational/geodetic "up", so you'd need probably a good leveling mechanism plus an inertial device, (if you want to be moving). And a reference to correct geodetic up to elliptical up (similar to a magnetic declination, but for gravity).
But even military quality geodetic transits can only get your longitude +/-100yds, plus they weigh a few hundred pounds, need to be manually set up, leveled, and a person has to do the actual observation (click a button as a star passes through the crosshair).
Granted this is decades old technology, (and I think actually used a electronic-mechanical computer) but I don't know that much has changed since then, at least in the unclassified world.
I believe ships at sea doing it manually with a sextant or similar device are only going for accuracy in the magnitude of 1-10 nautical miles.
So depending on what you're trying to do, it's questionable how much this might help you.
> You still need an accurate clock even if you can use a view of the sky, right?
Yup. In the 18th century figuring out a way to get accurate enough time at sea to allow accurate navigation was one of the most pressing problems for the various countries trying to establish themselves as major players in the New World.
Whichever country figured it out first would gain a significant military and economic advantage for as long as they could keep it secret.
An excellent book about this is "Longitude" by Dava Sobel [1].
I expect that whatever ephemerides the military uses are perfectly capable of handling UTC-TAI offset (and relativistic correction and refractive correction and orbital perturbation and speed-of-light correction for the observer’s location and pretty much any other error you can think of).
Whether the instruments being used are precise enough for any of this to matter is a different story. I’m quite curious whether military clocks correct their own relativistic errors. Military satellites almost certainly do.
The Navy is historically in charge of keeping official time in the US, and many other countries.
It's not that they can or can't make adjustments vs any other standard of keeping time, it's that they don't have to.
Whatever may (or may not) make sense today, we adjust to Navy time, because that's what's official, and that's what GPS time is ultimately based on.
Re, relativistic corrections, I don't know the answer for sure, but they average the time between multiple (I think cesium?) atomic clocks. If those clocks all shared the ~same reference frame, I'd think, by definition, you'd not need to make a relativistic adjustment. The frame you'd reference to is the one you're already in.
"Lots of critical military devices still use star based navigation,"
ICBM's inclusive. I've always thought it poetic that if humanity destroys itself, one of its final acts of comprehension will be that of a robot contemplating the heavens. We end as we began.
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.
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.
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.
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.
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.
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.
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).
44 comments
[ 2.1 ms ] story [ 123 ms ] threadIt'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.
https://en.wikipedia.org/wiki/Leap_second#International_prop...
But those dozen IT people think the trade off is really worth it (for them)!
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.
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.
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.
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.
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... (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-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)
With two points that should narrow down the position to two possible locations (with rather large uncertainty).
Edit: thinking about it further knowing north would reduce it down to 1 point. You also need to know where you are in the world to know which way magnetic north is pointing. It would be 1 very fuzzy spot.
If you find Polaris, you have both a vector to north and an angle to calculate latitude. No other info needed for that.
So you only need 1 overhead star plus a clock to figure out approx longitude.
Magnetic north is only useful if you need help finding Polaris.
For celestial objects, The math is rather simple. It is the intersection of 2 circles. The refence between the two objects would resolve which intersection is the correct one.
For magnetic north and 1 celestial object, the math is much more complex. Magnetic declination changes depending on where you are. You have to know roughly where you are before you start using it.
Polaris is important because it doesn't move, relative to the rest of the sky rotating around it.
You measure the angle from Polaris to geodetic "up" and that's the complimentary angle to your latitude. There is no complex math, just 90-x=y
If you have the time in London, and can observe the sun at its peak (solar noon) then you have longitude (after converting hours to degrees, and keeping minutes and seconds).
Or with an almanac, you can measure pretty much any known ID'd star or the sun at any time, and look up longitude from that.
Reinventing the wheel isn't needed, it's been the same process for centuries.
You don't measure angle to the horizon, but angle from gravitational/geodetic "up", so you'd need probably a good leveling mechanism plus an inertial device, (if you want to be moving). And a reference to correct geodetic up to elliptical up (similar to a magnetic declination, but for gravity).
But even military quality geodetic transits can only get your longitude +/-100yds, plus they weigh a few hundred pounds, need to be manually set up, leveled, and a person has to do the actual observation (click a button as a star passes through the crosshair).
Granted this is decades old technology, (and I think actually used a electronic-mechanical computer) but I don't know that much has changed since then, at least in the unclassified world.
I believe ships at sea doing it manually with a sextant or similar device are only going for accuracy in the magnitude of 1-10 nautical miles.
So depending on what you're trying to do, it's questionable how much this might help you.
Yup. In the 18th century figuring out a way to get accurate enough time at sea to allow accurate navigation was one of the most pressing problems for the various countries trying to establish themselves as major players in the New World.
Whichever country figured it out first would gain a significant military and economic advantage for as long as they could keep it secret.
An excellent book about this is "Longitude" by Dava Sobel [1].
[1] https://en.wikipedia.org/wiki/Longitude_(book)
Whether the instruments being used are precise enough for any of this to matter is a different story. I’m quite curious whether military clocks correct their own relativistic errors. Military satellites almost certainly do.
It's not that they can or can't make adjustments vs any other standard of keeping time, it's that they don't have to.
Whatever may (or may not) make sense today, we adjust to Navy time, because that's what's official, and that's what GPS time is ultimately based on.
Re, relativistic corrections, I don't know the answer for sure, but they average the time between multiple (I think cesium?) atomic clocks. If those clocks all shared the ~same reference frame, I'd think, by definition, you'd not need to make a relativistic adjustment. The frame you'd reference to is the one you're already in.
ICBM's inclusive. I've always thought it poetic that if humanity destroys itself, one of its final acts of comprehension will be that of a robot contemplating the heavens. We end as we began.
The first issue has already been found: https://twitter.com/uputronics/status/1418990637299519493
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.
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.
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
1. http://www.leobodnar.com/shop/index.php?main_page=product_in...
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