Consider adding GPS time scale - #1879

@taldcroft - the conversation on astropy somewhat confused me: I didn't see an actual use case for having GPS as a time scale rather than a format.

I also find it a bit odd in a practical sense, since GPS is steered continuously to match TAI as close as possible, but this is "only" within a 100 ns or so. If we really were to support GPS as a time scale, would we not need to interpolate in the (known) corrections? But this comes down again to what it would be used for.

@mhvk - I basically agree that I don't see a use case, but I was swayed to at least consider this by two web pages that come up on googling "gps time":

http://www.leapsecond.com/java/gpsclock.htm

This one shows GPS time on the left in ISO format as if it were a scale, in addition to showing it in weeks and seconds from the epoch time.

http://tycho.usno.navy.mil/gpstt.html

This one also discusses GPS time as if it were a scale, with repeated references to the differences with other scales.

This weekend by chance I was talking with a friend who actually designs sat nav systems for a living and he was talking about a problem they had with the GPS time which was being exchanged between satellites for docking. In this case it was clear that GPS time was a floating point number because it was being expressed with limited bit precision that rolls over each 10 years. As it happened the first time the satellites exchanged times, one of them appeared to be 10 years in the past.

@taldcroft - the second web site is exactly what led me to the opposite conclusion! Or more precisely, to my statement that if we were to consider it as a time scale, we should do it properly, and account for the drifts/offsets that the USNO folks measure/correct for.

p.s. If we do go for the scale anyway, should we perhaps make unix and cxc (or xmm!) scales as well? Certainly, any time I do ls -l, I get a rather different format than seconds since some time in 1972...

I think I'm with @mhvk here - yes, GPS is a scale, but a rather complicated one that probably isn't worth the effort to implement "correctly".

Even if we don't implement it for the near-future, perhaps a note should be added in the docs about this, @taldcroft ? Then at least it will be clear what we mean (even if the terminology in general is a bit ambiguous).

@eteq @mhvk - I added code to clarify the documentation. I'm fully on board with leaving it at that to close this out. Let me know if the docs are good enough.

I was just wondering if there should be some qualification like:

... considered as a time scale which is ahead of TAI by a fixed 
offset (to within 100 nanosec accuracy).

Oh, and I like it better with the (to within 100 nanosec accuracy) included in there, just so its clear that its a small effect. With that (and my comment above), I think this would be fine to merge/close.

@eteq - without waiting for Travis sphinx build, did I get the Notes format right?

Never mind, I just built locally and it looks fine. Merging.

Huh, I actually thought it was supposed to be --- instead of ===. Maybe it doesn't matter if there aren't other headings in that section (or I might just be confused). Anyway, as you say, it seems to be working just fine.