What's the reasoning for the current GPS time format and it's resulting issues? Can't we just use a 64bit integer timestamp? That would give us roughly 580 years in nanosecond resolution?
That's not an exaggeration for comic effect. There's literally 50 bits per second from each satellite. 6.25 bytes.
So the navigation messages are packed extremely densely. To the point that plenty of numbers don't even start on byte boundaries.
GPS relies on receiving extremely weak signals, often with a very limited receive antenna. This means there's a real trade off- you can send a limited amount of data over a given communication channel. Increasing the data rate might require increasing the transmit power / antenna gain of the GPS satellites, or requiring bigger / better receive antennas on GPS receivers.
Here are the parameters involved: https://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theore...
GPS satellites and receivers last on the order of 20 years so it takes a long time to age out of legacy support. The latest generation of satellites, GPS-III, have a new week number format that allows for 13-bit week numbers (120 year rollover).
The reason for the low number bits in week number is simple, it's broadcast on a very low bit rate (50 bits per second) and every frame has the week number in it. So you get faster fixes if you don't pad out with useless zeros.
It should be noted that the coders could have used data windowing and pivot dates to make certain assumptions:
> When ntpd(8) receives an unresolved timestamp from an upstream server, that timestamp could be based in any era prior to the current wall-clock date - but by definition we may not know the wall-clock date with confidence yet (not having achieved sync).
> To resolve this ambiguity, NTP also uses an internal pivot date. It chooses the era that would minimize the absolute value of the time difference between the resolved timestamp and its internal pivot date.
> This resolution technique is part of the NTP specification. It will normally resolve to the current era, but may in cases where the pivot is within a half-cycle of a rollover time resolve to either the previous or the next era.
> An ntpd(8) instance’s pivot date will be the date it was compiled and built.
> It is fairly easy to see that this guarantees correct resolution if the pivot dates of the communicating ntpds are within a half-cycle (88 years) of each other, even if there is a rollover between the pivot dates.
There have been some efforts to modernize the GPS signal format. In 2014, select GPS satellites began broadcasting an additional message (CNAV) with a 13 bit week number, allowing a ~157 epoch.
Somebody wanted to save money when building the original satellites in the 1970s.