GPS does not account for leap seconds (2002)
leapsecond.com
leapsecond.com
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.
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.
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).
There's a draft for NTPv5 (https://datatracker.ietf.org/doc/draft-mlichvar-ntp-ntpv5/) which allows the use of TAI instead of UTC.
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".
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?
GPS time, as in the actual timestamps used in the protocol, are an absolute scale like TAI. However, most GPS devices that you use will convert this to UTC using a leap seconds table. Just like literally everything else on the planet. Most of the time when people say "GPS time" what they mean is UTC using a GPS reference. However in physics and astronomy you do find people using GPS absolute scale times directly.
There is no problem here. GPS works exactly the way it should. Leap seconds are annoying but they're a civil convention not a technical limitation. Personally I'm all for abolishing them. By the time the drift actually matters to every day lives we'll likely have technological infrastructure so different the idea doesn't even make sense.
I have to add that GPS messages include TAI-UTC offset. That means that user of even old, non-internet-connected GPS receiver that didn't have any software updates in a decade, will still read out exact UTC time with cumulative leap seconds correctly applied.
I have many fine examples of early to mid 1990s GPS receivers which can, eventually, get the full almanac and determine the geographical coordinates, but can't correctly figure out what day it is.
Realistically that is only a problem for devices not yet supporting the 13 bit week field or if we still use GPS in 150 years and even then heuristics could solve this problem unless devices exist that without software updates will live for longer than ~100 years.
The concern about drift reminds me of all those programs written in the 1990s which meticulously ensured century years weren't counted as leap years, but didn't bother with the 400 year exception to that exception. Which meant they'd have worked perfectly well for hundreds of years... except in the year 2000 which was near at hand. Hilarious.
I agree we should abolish leap seconds. Have civil time (UTC) track TAI.
<flame>IMHO, in the perfect world, this is how the leap second should have been handled in all computer systems. The international atomic time (TAI), without leap second, should be used for internal timekeeping in computers. The UTC leap second adjustment should be handled as an external offset, similar to timezone data.</flame>
Galileo and BeiDou behave similarly to GPS in this respect. Oddly enough, all three time bases have an origin that is specified in UTC, but model elapsed seconds since that epoch. So GPS time does include the 9 leap seconds which occurred prior to its epoch. Galileo time's epoch is aligned to the GPS week, so it shares a leap second offset with GPS, but its still specified in terms of UTC (1999-08-21T23:47). BeiDou's epoch is specified as 2006-01-01T00:00 UTC, so it includes another 14 leap seconds with respect to GPS. So the three systems do not quite model the platonic ideal, but fortunately the offsets are all constants and its trivial for the receiver to use such an ideal in practice.
GLONASS time is UTC + three hours (ie, Moscow civil time) and does have leap seconds. To figure out the leap second offset between GLONASS time and GPS time the GLONASS ICD actually tells you to get that info from the GPS broadcast messages, although they do have an alert system for upcoming leap second updates. One more reason to dislike working with GLONASS.
The page is a javascript animation of "GPS system time", UTC, and TAI showing how they all tick together but are offset from each other by an integer number of seconds. It's a fixed integer in the case of TAI and GPS and a variable integer in the case of UTC.
Google's 24-hour smear makes leap seconds, bad enough already, ever so much worse.
We could fix the problem just by never announcing another one.
Fixing UTC just means not announcing any more leap seconds. Not doing a harmful thing anymore is always the best fix.
[1] The first leap hour, which would happen when DUTC is around 30 minutes, will happen around the late third millenium (https://www.ucolick.org/~sla/leapsecs/dutc.html) and by that time we will regularly have 6 leap seconds per year. Steve Allen is a sort of proponent for leap seconds and not much for leap hours, but to me this projected table is the best argument for leap hours.
They needen't have done that - GPS would work just fine without transmitting that information globally on a very low data rate carrier (50 bits per second), where every bit sent degrades the service (longer position locking time for everyone).
Operating systems that adjust the computer's hardware clock on leap seconds (all of them?), are also wrong.
It's not like NTP time is adjusted by 24*60*60 on any leap day. So why on leap seconds?
The whole leap second disaster is just beyond imagination - inserting a full second into the system during business hours in Asia when some of the world's largest exchanges are in trading session! When there are hundreds of millions time sensitive devices manufactured by tens of thousands different vendors at vastly different skill levels!
When compared with this leap second invention, Y2K problem is so harmless.
Too bad there weren't any computers around at the time or software developers might have convinced Julius Caesar what a disaster and source of bugs that will be for centuries to come. He might have dropped the whole idea.
I think the concept itself is fine, but software developers screwed up implementing it when designing unix and NTP time, or how operating systems handle hardware clocks.
Now there are unix and NTP timestamps that don't refer to a unique time point due to leap seconds, as they were rewound by a second at the time point when the leap second occurred. Somehow nobody thought that it would be a good idea for unix and NTP times to be rewound by a whole day after a leap day occurs.
That is pretty fine tuned given they only insert a full day. ;)
In Chinese lunar calendar, and probably other calendars as well, they insert a full month known as the leap month. Yes, you hear me right, 13 months in such leap years.
> Too bad there weren't any computers around at the time or software developers might have convinced Julius Caesar what a disaster and source of bugs that will be for centuries to come. He might have dropped the whole idea.
Indeed. Such 2000 years old garbage is just not very compatible with modern way of life in which lots of things are being changed. From memory, in a few years, the definition of a second will also be reviewed by the international community. The current definition based on some funny behavior of Caesium atom is no longer the best. UTC is another drama deserve to have more care.
My intent wasn't to be misleading, it was a function of my surprise that I didn't know that. UTC plays a big part of my professional life, and it never occurred to me GPS wasn't the same, even though it is obvious in retrospect. As many commenters said, what are they going to do, update the satellites?
It was just interesting to me that two highly precise systems don't overlap.
As it turns out, yes, GPS satellites are regularly updated to have leap second data available
Negative leap seconds are even worse than regular leap seconds.
Makes sense if you consider that GPS relates to the Earth, but leap seconds apply to the relationship between the Earth and the Sun.
Of all GNSS systems, GLONASS is the one that is intrinsically connected to leap seconds as it syncs up to Moscow time (UTC+3), instead of basing on TAI, TAI+3 or another monotonic timer. This causes problems (https://eos-gnss.com/knowledge-base/articles/technical-bulle...).
The GPS signal pre-announces upcoming leap seconds a few months in advance. Devices can then use that information to correctly adjust the difference in time.
[1] A lot of programmers like to order events by system time. This is dangerous normally, but NTP helps sweep most of the danger under the rug. If some of your NTP servers serve UTC and some show GPS time, you're almost guaranteed to have very messy system time across your fleet and anything that expects orderly time is out of luck.