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.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
