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.
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.
> 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.
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.
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.
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).
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.