2

My GPS is reporting dates from the previous epoch. How many microseconds should I add to the date to get the correct value?

Since the 2019 GPS Week Number Rollover, my old GPS logger (QStarz BT-Q1000X) has started reporting that the current GPS date is in 1999. I think I can fix it by re-writing the logging software to add a constant value to the timestamps. But what constant? The software is written in Java, which measures time as the number of microseconds since midnight at the start of 1 Jan 1970, so I need a value in microseconds.

From the answer to What is a GPS epoch? I understand that GPS time is measured in weeks and seconds from 6 Jan 1980. In this sense, the length of the GPS epoch is the time taken for the week number to roll over. This is 1024 weeks (as it is stored as a 10-bit number) or about 19.7 years. Hence the second GPS epoch started on 22 August 1999, and the third on 7 April 2019.

The simple calculation is that I should add on 1024 weeks * 7 days * 24 hours * 60 minutes * 60 seconds * 1000 = 619 315 200 000 ms. But is this right? Do I need to account for leap seconds, non-integer numbers of weeks/year or hours/day, etc? In short, is there anything else non-obvious I need to take into account?

For my application, I don't need accuracy better than to the nearest second, and I realise that there is a difference between GPS time and UTC. What I'm after is values that are reasonably accurate with respect to current GPS time.

More relevant background:

  • There are leap seconds as well to consider > stackoverflow.com/questions/16501531/… – Mapperz May 24 at 3:11
  • @Mapperz As I said in the question, I am aware of leap seconds, but should I take them into account in my context? If so, how many? The responses to the question you've linked to seem to disagree on whether they need to be accounted for. Also, that question was about the elapsed time since the start of an epoch, which is subtly different from what I am asking. – JRI May 24 at 10:41
  • Per leap second wikipedia GPS navigation uses the linear GPS time scale, as a one-second leap would cause a location error of up to 460 meters (1⁄4 nautical mile). --Meaning you may not need to worry about leap seconds? – KHibma Sep 12 at 18:36
  • Another interesting link - leapsecond.com/java/gpsclock.htm – KHibma Sep 12 at 18:41
0

This turned out to be relatively easy to answer. In Java, you can calculate the length of an epoch like this:

public class epoch {
    public static void main(String[] args) {
        java.util.Date epoch2 = new java.util.Date(119, 3, 7);    /*  7 Apr 2019 */
        java.util.Date epoch1 = new java.util.Date(99, 7, 22);    /* 22 Aug 1999 */
        System.out.println(epoch2.getTime() - epoch1.getTime());
    }
}

For me, this gave 619 315 200 000 ms, the number I had guessed. This implies that my system (Java SE 1.8.0 on Windows 10) ignores leap-seconds and assumes all days are 86 400 s long. I got the same result with similar code in JavaScript too. It is possible, but unlikely, that some other systems might return a slightly different number, if they use UTC time and take leap-seconds into account.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.