4 ms·

This is a very misleading post. GPS time, as in the actual timestamps used in the protocol, are an absolute scale like TAI. However, most GPS devices that you

This is a very misleading post. 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.

nousermane 4y ago
Very misleading article indeed. 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.
- terinjokes 4y ago
  Well, they would, if they knew which epoch they were in, which isn't transmitted by the satellites, and on many receivers, isn't something an end user can easily change. 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.
  - nousermane 4y ago
    Ah, yes. The infamous 1024-week (19.5 years) GPS epoch. I take back my "two decades" claim.
    - terinjokes 4y ago
      I think with some of my Garmin units you can connect them via serial and use an old Windows 98 application to sync the current PC time, which it will use as the basis for figuring out what week it's in. I haven't gotten the application working though.
  - the_mitsuhiko 4y ago
    > Well, they would, if they knew which epoch they were in, which isn't transmitted by the satellites 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.
    - deleted 4y ago
      [deleted]
- jasonwatkinspdx 4y ago
  I'd forgotten that. Thanks for the correction :).
tialaramex 4y ago
> 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. 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.
- thombat 4y ago
  Most of the pre-Y2K programs I saw were dumber: their leap year test was simply "year mod 4 = 0". So they were going to falsely report a century as a leap year BUT were saved by the fact that the next century number was divisible by 4. Sort of "two dumbass decisions make a right"

nousermane 4y ago

Very misleading article indeed. 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.

terinjokes 4y ago
Well, they would, if they knew which epoch they were in, which isn't transmitted by the satellites, and on many receivers, isn't something an end user can easily change. 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.
- nousermane 4y ago
  Ah, yes. The infamous 1024-week (19.5 years) GPS epoch. I take back my "two decades" claim.
  - terinjokes 4y ago
    I think with some of my Garmin units you can connect them via serial and use an old Windows 98 application to sync the current PC time, which it will use as the basis for figuring out what week it's in. I haven't gotten the application working though.
- the_mitsuhiko 4y ago
  > Well, they would, if they knew which epoch they were in, which isn't transmitted by the satellites 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.
  - deleted 4y ago
    [deleted]
jasonwatkinspdx 4y ago
I'd forgotten that. Thanks for the correction :).

tialaramex 4y ago

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

thombat 4y ago
Most of the pre-Y2K programs I saw were dumber: their leap year test was simply "year mod 4 = 0". So they were going to falsely report a century as a leap year BUT were saved by the fact that the next century number was divisible by 4. Sort of "two dumbass decisions make a right"