GPS does not account for leap seconds (2002)

After a couple of decades in instrument design and field use (geophysics, astrophysics, other) it&#x27;s perhaps worth pointing out for the umpteenth time that NO &quot;scientific&quot; or or other time series aquisition should ever &quot;account for leap seconds&quot; | use UTC etc.<p>If any at all requires a &quot;delta-T&quot; (lapsed time between) then a true delta-T is needed, not some correction to an earth based notion of noon.<p>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)).<p>&quot;Raw GPS Sat time&quot; - the super raw satellite frame uses a monotonically increasing count of lapsed seconds <i>of satellite time</i> that resets on a weekly basis.<p><i>Satellite time</i> 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.<p>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.

This is a very misleading post.<p>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 &quot;GPS time&quot; what they mean is UTC using a GPS reference. However in physics and astronomy you do find people using GPS absolute scale times directly.<p>There is no problem here. GPS works exactly the way it should. Leap seconds are annoying but they&#x27;re a civil convention not a technical limitation. Personally I&#x27;m all for abolishing them. By the time the drift actually matters to every day lives we&#x27;ll likely have technological infrastructure so different the idea doesn&#x27;t even make sense.

The phrase &quot;does not account for leap seconds&quot; is highly misleading. Sure, the internal GPS time does not include leap second, but the GPS system also broadcasts the leap second offset for conversion to UTC. Also, before a leap second adjustment is made, it also generates leap-second announcements.<p>&lt;flame&gt;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.&lt;&#x2F;flame&gt;

Author of the web site (leapsecond.com) here if you have any questions. I don&#x27;t know how the title of the HN post was chosen. The actual title of the web page is &quot;GPS, UTC, and TAI Clocks&quot;.<p>The page is a javascript animation of &quot;GPS system time&quot;, UTC, and TAI showing how they all tick together but are offset from each other by an integer number of seconds. It&#x27;s a fixed integer in the case of TAI and GPS and a variable integer in the case of UTC.

This title--&quot;GPS does not account for leap seconds&quot;--makes it sound like &quot;GPS would not handle leap seconds&quot;, and has already confused another commenter, but GPS is just trying to provide a universal time reference and the concept of leap seconds can be (and is) then applied locally as a conversion from GPS to whatever your local time measurement &#x2F; display is (which, for all GPS cares, is the Swatch .beat). So like, sure: it doesn&#x27;t itself track leap seconds, but &quot;account for&quot; is too heavy as the overall usage of GPS certainly does and the design isn&#x27;t somehow unable to support the concept.

IMO a monotonic time source should never ever adjust to leap seconds, it&#x27;s just stupid. GPS time does this right, and IMO NTP time does this wrong.<p>Operating systems that adjust the computer&#x27;s hardware clock on leap seconds (all of them?), are also wrong.<p>It&#x27;s not like NTP time is adjusted by 24*60*60 on any leap day. So why on leap seconds?

In 2022, there are not many international matters that can be agreed upon by US, EU and China at the same time. Getting rid of this stupid leap second disaster is one of those rare ones. US, EU and China all agreed that leap second should be eliminated. It is a disaster.<p>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&#x27;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!<p>When compared with this leap second invention, Y2K problem is so harmless.

Edited the title to add &#x27;(by design)&#x27;, and even &#x27;account for&#x27; was poorly phrased.<p>My intent wasn&#x27;t to be misleading, it was a function of my surprise that I didn&#x27;t know that. UTC plays a big part of my professional life, and it never occurred to me GPS wasn&#x27;t the same, even though it is obvious in retrospect. As many commenters said, what are they going to do, update the satellites?<p>It was just interesting to me that two highly precise systems don&#x27;t overlap.

GPS time was intentionally designed not to be perturbed by leap seconds. Other time sources based on atomic clocks have this property too.<p>Makes sense if you consider that GPS relates to the Earth, but leap seconds apply to the relationship between the Earth and the Sun.

How could it, it is not clairvoyant

So, if you have a GPS device hooked to, say, a Mikrotik Router (which I have done previously) and use that GPS for NTP time, is it 18 seconds off, or is there magic? Or, say, the same for a Linux box using GPS for NTP?