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