Comment by defrost | Hacker News Reader

Comment by defrost | Hacker News Reader

Parent Full thread

After a couple of decades in instrument design and field use (geophysics, astrophysics, other) it's perhaps worth pointing out for the umpteenth time that NO "scientific" or or other time series aquisition should ever "account for leap seconds" | use UTC etc.

If any at all requires a "delta-T" (lapsed time between) then a true delta-T is needed, not some correction to an earth based notion of noon.

The correct way (with multiple instruments) is with calibration runs to establish parameters and frequent (at the very least at start and end of aquisition runs) syncronisation signals or events, and for each isolated cluster of instruments to have an epoch counting clock (a sufficiently fine resolution incremental counter of time units lapsed since X (for varying X)).

"Raw GPS Sat time" - the super raw satellite frame uses a monotonically increasing count of lapsed seconds of satellite time that resets on a weekly basis.

Satellite time being a moving frame in a reduced gravity locale .. so a time frame in which atomic clocks do not run as they do at ground level and at nominal 1G.

This, of course, varies for each satellite and is reconciled by a ground station which transmits a correction frame for position and time back to each satellite to pass on to handheld recievers.

> NO "scientific" or or other time series aquisition should ever "account for leap seconds" | use UTC etc.

Great idea in theory - just using TAI is a very pure solution.

But if you want to use any major programming language or spreadsheet you'll find the standard libraries support Unix timestamps, UTC, and Local time - but not TAI.

And unless you've got very reliable equipment, you're probably used to occasional blips in your data, so a 1 second blip is probably tolerable.

So I can understand why, outside of astronomy, many projects end up ignoring leapseconds.

In theory?

Engineering, aeronautics, physics, embedded boards, etc have been using "real elapsed time" w/out recourse to UTC | time servers | TAI for a good forty years in practice already.

> And unless you've got very reliable equipment, you're probably used to occasional blips in your data, so a 1 second blip is probably tolerable.

Leap seconds can go in either direction, so far they've consistently jumped one way (and caused no issue in any of the 24/7/365 data aquisition projects I've worked since the mid 1980s as we don't tie ourselves to time servers for real enginerring with actual lapsed time intervals).

I suspect you'll find software that doesn't account for time running backwards when using a delta-T for something critical won't just be forgiven for having a "blip".

This is a real dilemma when doing scientific data acquisition for years rather than short shots.

NTP uses the UTC time standard but there are GPS time sources that can distribute other time standards over NTP and PTP. What breaks when you do this? Is it a worthy tradeoff?

Note that this is a concern of coordinating timestamps generated by devices that support PTP and devices that only support NTP (as many slow datarate devices do).

This is a very poor design decision in retrospect, NTP should have always used TAI. But it's too late to change it. Unfortunately, not enough people know about this problem or even just about the existence of TAI.

> NTP should have always used TAI. But it's too late to change it.

There's a draft for NTPv5 (https://datatracker.ietf.org/doc/draft-mlichvar-ntp-ntpv5/) which allows the use of TAI instead of UTC.

I'm not sure how this would solve the problem in my lifetime. PLC manufacturers are not known for fast adoption. Why would they ever update a working NTP implementation?

I am currently working on a "multiple instrument" setup acquisition with a GPS PPS and a standard reference clock distributed to multiple machines. It is exactly as you said, each instrument has a free-running incremental counter that is reset on every PPS.

If I want to do long delta-t calculations, what is the correct strategy to correlate these acquisition runs to wall-clock time?

Do I record the start time as given by the (PTP disciplined) system clock clock_gettime(), then schedule an acquisition to start at the next PPS/sync? How does one ensure that the recorded "start time" is actually the correct time?

If for example I would like to start acquiring at t=0, at t=-1 I would record the current UTC time (call it system_time), schedule an acquisition to start on the next sync/PPS, and then record the start time as system_time + 1. It seems to me that this would fail if a leap second were inserted at t=1.

Is it perhaps better to do my calculations in CLOCK_TAI, add one second, and then convert back to UTC?

Or, just record everything in TAI?

Reply on news.ycombinator.com