Add TimeGPS class to Time (=seconds since 1980-01-01 00:00:00 UTC = TAI -19 s - #1164

Not sure why the travis build with sphinx failed. Suggestions?

@mhvk - this is a known issue that I think @eteq fixed in master - I'll restart the Travis build

@mhvk - From what I understand (http://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping) GPS time is really a time scale, not a time format (which is what you implemented). It is defined by TAI - GPS = 19 sec. I suspect that your colleague would want to the following behavior:

>>> t = Time('2000-01-01 12:00:19', scale='tai')
>>> t.gps
'2000-01-01 12:00:00'

What you implemented will instead give a float number. In the case of cxcsec or unix that float number is directly useful, but I'm not sure about GPS.

Implementing a new time scale should not be too difficult, particularly in this case.

@taldcroft - OK, I may have misunderstood what was requested; I've asked David to comment, and also pinged one of our local LIGO people, Kipp Cannon.

@taldcroft - my colleague answered (I'll get him to contribute himself yet ;-):

But specifically what we & LIGO want is something like that given at:
http://www.andrews.edu/~tzs/timeconv/timeconvert.php
I have tested that against the PHP version discussed at:
http://www.andrews.edu/~tzs/timeconv/timealgorithm.html
and our own python implementation, and they all match. We use gpstime as a unique way to label all events that will increment in a predictable way. The translation from gpstime <-> UTC is well defined, with the possible exception of during a leap second.

Our local LIGO expert wrote

We essentially use it as a monotonically increasing counter with which to label things. As such, we consider a "GPS time" to be a count of seconds since the GPS epoch. They are only useful to us in that format. Expressing a GPS time as a Gregorian year/month/day/hour/minute/second would create confusion.

So, happily it seems I managed to get the use case right!

OK, looks like this is mostly good, just some minor documentation comments.

@taldcroft - OK, thanks, all good changes - now implemented.