
Unsmear: Convert to and from timescales with smeared leap seconds - fanf2
https://github.com/google/unsmear
======
brandmeyer
(Dustin Hoffman's voice) I hate, I Hate, I HATE Smeared Time!

I must admit my own personal bias in this matter, because I am in the process
of implementing a GNSS receiver that very much cares about both the speed and
phase of time. It seems that the computing industry would rather define the
second based the mean solar day of Earth's rotations, despite the rest of the
world defining it to be the number of shakes of a Cesium atom partway down
Earth's gravity well.

But instead of slaving their clocks to the international system that actually
measures the mean solar day (UT1R), they decided to muck with both the speed
and phase of time. For just one 24 hour period. Every once in a while.

If I was king for a moment, and could pronounce just one edict it would be
this: To transmit UT1R's offset in the GPS C/NAV message, and demand that the
NTP timebase slaves itself to that.

~~~
perilunar
> despite the rest of the world defining it to be the number of shakes of a
> Cesium atom partway down Earth's gravity well.

Hang on, the number of shakes should be the same regardless of where you are
in a gravitational well.

~~~
brandmeyer
The timebases which are transmitted by the GNSS systems are in turn
synchronized to the TAI network, which are all located on Earth's surface.
Time does appear to be passing noticeably slower on Earth's surface compared
to precision clocks in orbit. Even on the surface if you measure very
carefully, you'll find that the SI second varies with respect to TAI depending
on your altitude above mean sea level, too.

Civil time is therefore already partly divorced from the SI second due to this
effect. Why not divorce it the rest of the way?

~~~
perilunar
I'm not disputing that clocks at altitude _appear_ to run faster relative to
clocks at sea level - as you said _time_ is passing slower down here. But a
second is always and everywhere the same 'number of shakes' locally.

------
est31
> Although this is not an officially supported Google product, you can reach
> us on the unsmear-discuss mailing list.

I'd say that this component has probably much better support than any of those
"officially supported" Google products. Not wanting to blame Google for this
though, they have billions of customers and providing good customer support
for them would be insanely expensive.

------
zokier
Why were leap seconds (basically utc vs tai) accepted so readily and widely?
What does it matter if civil vs solar time would have slowly drifted 10
minutes over a millenia or something like that?

~~~
AstralStorm
Almost every device would be inaccurate and impossible to synchronize with
military standards, causing huge headaches in defense industry.

Why not instead use a correct second?

~~~
steerablesafe
GPS time has no leap seconds though.

------
wmf
Oh man, I thought the point of smearing is to avoid the need for such
conversions.

~~~
tedunangst
Smearing is very convenient if you use it because time stays "normal". But if
you need to precisely correlate with outside sources, what other option do you
have?

~~~
wmf
So when _do_ you need subsecond-acccurate correlation of timestamps with
outside sources?

~~~
brandmeyer
My ground control systems are sitting in a hosted datacenter with an entirely-
unlike-UTC timebase.

My satellite is synchronized to TAI via GPS time.

I coordinate with a third party who manages the ground-based radio to
coordinate contacts with my satellite system.

If something goes wrong, it would be nice to compare the logs from the three
systems after a contact to see which node thought what was going on.

The fact that one or two of those systems gets its time from a not-UTC source
makes this problem harder than it needs to be.

------
1-6
Entering "2016-12-31 23:59:60" in a POSIX converter will fail and XML will
reject such entry as "invalid time".

