4 ms·

Kind of, but differences in time will forever deviate from the SI second so I don't think that really counts. Also 0.0001% of the distance to a GPS satellite i

Kind of, but differences in time will forever deviate from the SI second so I don't think that really counts. Also 0.0001% of the distance to a GPS satellite is on the order of 200m. Not impossible to work with, but not great either. Though I have no idea what the exact ramifications would be.

sebzim4500 5y ago
Right but as long as GPS satellites are synchronised with each other it doesn't matter all that much how synchronised they are with anyone on the ground, the position they return will still be correct.
- brandmeyer 5y ago
  Take a good hard look at the GPS interface specification. The GPS satellites aren't synchronized with each other*. They are synchronized with the ground control segment. https://www.gps.gov/technical/icwg/IS-GPS-200K.pdf https://www.gps.gov/technical/icwg/IS-GPS-200K.pdf * recent satellites have limited autonomous navigation capability as a backup.
- contravariant 5y ago
  You still end up with a bunch of messages that end up saying "at time T I was at position X" where T is off in absolute terms (which you indeed can solve by using an additional satellite to synchronize your clock) and is measure with a different rate (which you cannot solve, unless you know a leap smear is occurring, or by using yet another extra satellite and some mathematics that I don't think anyone's ever bothered working out yet).
nextaccountic 5y ago
Let's call the Google proposal UTC_smear. You can simply convert between UTC and UTC_smear and vice versa just fine. You just need to be extra careful to store each timestamp with their corresponding time format. Just like you can convert between UTC, TAI and UT1.
vitus 5y ago
> Kind of, but differences in time will forever deviate from the SI second so I don't think that really counts. I don't follow. Outside of days with a leap second, you are using the SI second. If you're measuring skew via raw-seconds-since-epoch or something similar, that's already an error-prone measurement. It's a non-goal for smeared UTC to be synchronized with TAI, just as it's a non-goal for unsmeared UTC to be synchronized with TAI.

sebzim4500 5y ago

Right but as long as GPS satellites are synchronised with each other it doesn't matter all that much how synchronised they are with anyone on the ground, the position they return will still be correct.

brandmeyer 5y ago
Take a good hard look at the GPS interface specification. The GPS satellites aren't synchronized with each other*. They are synchronized with the ground control segment. https://www.gps.gov/technical/icwg/IS-GPS-200K.pdf https://www.gps.gov/technical/icwg/IS-GPS-200K.pdf * recent satellites have limited autonomous navigation capability as a backup.
contravariant 5y ago
You still end up with a bunch of messages that end up saying "at time T I was at position X" where T is off in absolute terms (which you indeed can solve by using an additional satellite to synchronize your clock) and is measure with a different rate (which you cannot solve, unless you know a leap smear is occurring, or by using yet another extra satellite and some mathematics that I don't think anyone's ever bothered working out yet).

nextaccountic 5y ago

Let's call the Google proposal UTC_smear. You can simply convert between UTC and UTC_smear and vice versa just fine. You just need to be extra careful to store each timestamp with their corresponding time format. Just like you can convert between UTC, TAI and UT1.

vitus 5y ago

> Kind of, but differences in time will forever deviate from the SI second so I don't think that really counts. I don't follow. Outside of days with a leap second, you are using the SI second. If you're measuring skew via raw-seconds-since-epoch or something similar, that's already an error-prone measurement. It's a non-goal for smeared UTC to be synchronized with TAI, just as it's a non-goal for unsmeared UTC to be synchronized with TAI.