Unsmear: Convert to and from timescales with smeared leap seconds | Hacker News Reader

Unsmear: Convert to and from timescales with smeared leap seconds

github.com

51 pointsfanf223 comments

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

Time smearing is far from a "computing industry" standard. Has its use spread that far past Google and stuff running on their services?

AWS does it: https://aws.amazon.com/about-aws/whats-new/2017/11/introduci...

NTP can be configured to do it: https://docs.ntpsec.org/latest/leapsmear.html

Support for this is growing more popular with time, rather than less.

This is because the "cure" of a leap second is worse than disease.

How about we use actual correct seconds instead and get rid of the whole business?

I would be happy if computer clocks wouldn't be changed on leap seconds, just stick to TAI instead of UTC. We don't reset clocks/dates on DST and leap days, so why do we bother with leap seconds?

> We don't reset clocks/dates on DST

We don't?

Well, not computer clocks, they just run on UTC. Displayed clocks are adjusted with the appropriate time zone selected for them.

Thanks for clarifying!

Blame ITU.

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

The rate of shaking would appear to be different due to general relativity.

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?

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.

If you hate smearing, and it causes problems for you, then you're likely exactly the person this library is for.

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

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?

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?

GPS time has no leap seconds though.

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

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?

So when do you need subsecond-acccurate correlation of timestamps with outside sources?

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.

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

Reply on news.ycombinator.com