6 ms·

Smear it! You sacrifice 1 on days with leap seconds (by 0.001%), but otherwise have all three. https://developers.google.com/time/smear https://developers.goog

by vitus 5y ago

Smear it! You sacrifice 1 on days with leap seconds (by 0.001%), but otherwise have all three. https://developers.google.com/time/smear https://developers.google.com/time/smear

michaelt 5y ago
Ah yes, for people who want to support leap seconds, but who can happily ignore a clock error of 0.5 seconds :)
- vitus 5y ago
  I like to think of it as UTC being off by 1s just before the leap second. :)
- q3k 5y ago
  ... 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.
contravariant 5y ago
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.

by vitus 5y ago

Smear it! You sacrifice 1 on days with leap seconds (by 0.001%), but otherwise have all three. https://developers.google.com/time/smear https://developers.google.com/time/smear

michaelt 5y ago

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

vitus 5y ago
I like to think of it as UTC being off by 1s just before the leap second. :)
q3k 5y ago
... 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.

contravariant 5y ago

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.