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

[jimlux]

On 1/15/19 6:34 PM, Rob Seaman wrote:
> 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?
Ground processing only - for user convenience

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

Time is set by the messages from the OEM-6xx series GPS receiver and its 
1pps - It's GPS time, not UTC.

if there's a GPS outage, time propagates forward on the onboard 
oscillator which isn't great.  When GPS resumes, time jumps.




> 
> 
>> 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?

I think the folks at the labsat website just coded a naive implementation.


For this application, <1 second uncertainty is needed (technically, one 
can set events to occur to within 1 microsecond, but that's counted down 
from the 1pps using the internal clock, with the "correct" 1pps done by 
knowing it's week:second)


> 
> 
>> 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.

As it happens the ops aren't at JPL for this spacecraft.

And that's exactly how we can deal with it - it's perfectly reasonable 
to say "folks, there's a leap second a'coming, run for the hills til it 
gets here"

For spacecraft flying via JPL ops, we work in TAI (or also, MET - 
Mission Elapsed Time or SCLK - spacecraft clock), since all the nav is 
done that way.. we also have to deal with relativistic effects and light 
time - the whole "what do you do with time" on that scale has seen 40 
years of development.

> 
> 
>> 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?

or just set up an operational procedure that defines some file or 
something under configuration control that has the "GPS time" and the 
"Week:seconds" for the same time that is "after the last leap second".


> 
> 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.)

Not really - for those kinds of use cases there's already issues and 
solutions with reconciling local observations of clocks against outside 
time scales.

the "don't operate during the leap" and "keep track" work just fine.