[LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[jimlux]

On 1/15/19 11:41 AM, Rob Seaman wrote:
> Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of 
> IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The 
> various libraries and operating systems listed deal with none of the 
> reference time scales (GPS, UTC, or TAI, for that matter) completely and 
> correctly.
> 
> There's no obvious connection here with astronomical use cases. We rely 
> on our reference clocks' vendor to have implemented IS-GPS-200J and 
> relevant standards correctly. These devices operate off single board 
> linux cards, but I presume they wrote the critical code themselves to 
> handle leap seconds, but also other precision timekeeping issues not 
> entertained by POSIX and other mass market software. Our clocks handle 
> time scales other than UTC, but since our customer (NASA PDCO) specifies 
> UTC, that's what we deliver.
> 
> The bread-and-butter leap second discussions on this list seem 
> irrelevant to simply meeting an engineering requirement to adhere to 
> whatever standard. If POSIX, python, excel, whatever don't provide 
> canned tools to convert seamlessly between GPS and UTC, or to handle 
> format conversions from week:ms to sexagesimal, such tools must be 
> implemented outside those languages/libraries. There are a vast number 
> of other science-related data engineering details that POSIX (for 
> example) also does not implement.


Indeed - but before leaping[sic] into coding it up, I thought I'd ask 
around

You also asked..


 > /I'll probably test it for the cases I'm interested in (Ruby, Python,
 > Excel, Matlab, Octave), but if someone else has already done it, then
 > I've got something to cross check against./

I would add MySQL/MariaDB and PostgreSQL, as well as TCL and C/C++ to
that list. If JPL were to support libraries implementing some useful
subset of timekeeping utilities under a smorgasbord of such languages,
members of this list would undoubtedly be delighted to cross-check the
results and put them to good use (via GitHub or what have you).

---
I don't know that JPL is interested in a generalized library collection. 
It would be useful.. a sort of "cross platform" collection..  At JPL we 
tend to just solve the problem at hand, and release just that software.


---

That said, it isn't clear what the original use case involves. Something
about spacecraft using GPS week numbers and ground systems using UTC?
But what do you need to do exactly? And is this onboard or on the ground?


---

The use case is this - I have a satellite in orbit which does everything 
internally in terms of GPS week and millisecond of week.  Folks on the 
ground work in UTC, since that's what the plethora of PCs are using.

We want to synchronize an event on the ground with an event on the 
spacecraft, so, given that someone on the ground is going to do 
something on 21 January 2019 at 12:34:56Z, we need to be able to command 
the spacecraft to do that at the corresponding Week:Second.

Right now, they use a website

For example: https://www.labsat.co.uk/index.php/en/gps-time-calculator

which, by the way, doesn't use leap seconds, so it's off by some 18 seconds

Sometimes cross checked for consistency by, say, the page at
http://leapsecond.com/java/gpsclock.htm


It would be much easier for the operators if they could just *enter* the 
UTC time, and have the software calculate the GPS Week:millisecond (or 
vice versa)



Leap Seconds, should they occur, would be handled by "don't do anything 
around or across the leap second".
And, we could rebaseline the conversion

i.e. the calculation would be
SecondsAfterBaseDate = Seconds(UserEnteredDate) - Seconds(BaseDate)
DesiredTime = Seconds(6 Jan 1980) + SecondsAfterBaseDate
GPSWeek = Floor(DesiredTime/(86400*7))
GPSMilliseconds = (DesiredTime - GPSWeek*86400*7) * 1000

Which works quite nicely as long as the interval between BaseDate and 
UserEnteredDate does not include a leap second.