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

[Rob Seaman]

Hi Jim,

> 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.
>
Just to verify. The satellite does use GPS as its reference clock, not
some manual upload (in a similar way as you describe) from ground
stations? The routines you're talking about aren't (directly) affecting
the state of the clock on the spacecraft?

Or more simply, how accurate are the satellite's GPS week and
millisecond values?


> 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
>
Do they ignore the 18 seconds? What precision is required for this
application?


> 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".
>
Or could you simply forbid activities during a few hours of June 30 /
December 31? If the operators are at JPL this would be late afternoon on
whatever day of the week. That is, just assume there's always a leap
second at each opportunity.


> 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.
>
This conversion is so simple it seems unnecessary to rely on somebody
else's library. What you might need is to arrange for a local, reliable,
vetted copy of the leap seconds table. So perhaps folks here could
comment on their best practices for retrieving same in an operational
environment?

Note that if your use cases include retroactive requirements then even
if leap seconds cease you will need to maintain the leap seconds table
(perhaps compiled into the source through some date). (For leap second
warriors, redefining UTC makes it more complicated, not less, when all
use cases are considered.)

On the other hand, if your "plethora of PCs" keep good time (via NTP or
SNTP), and you don't care to better than a second (which your current
18s offset suggests might be the case), and there are no after-the-fact
use cases, do you need anything other than a procedural rule about
avoiding such activities at the end of June and December? That is, put
your effort into making your NTP installation as reliable as possible.

Rob Seaman, University of Arizona