Hacker News Reader

Comment by vitus | Hacker News Reader

Smear it! You sacrifice 1 on days with leap seconds (by 0.001%), but otherwise have all three.

https://developers.google.com/time/smear

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.

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.

https://www.gps.gov/technical/icwg/IS-GPS-200K.pdf

* recent satellites have limited autonomous navigation capability as a backup.

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

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.

Ah yes, for people who want to support leap seconds, but who can happily ignore a clock error of 0.5 seconds :)

I like to think of it as UTC being off by 1s just before the leap second. :)

... I wouldn't call it an error? It's an offset between smeared UTC and non-smeared UTC, like between any two other time standards.

It's internally consistent, and for communicating with external entities that expect unsmeared UTC you convert as needed as much as possible. No different from if you were running TAI and communicating with unsmeared UTC, or communicating with TAI while running unsmeared UTC.

Reply on news.ycombinator.com