GPS Time – How Long is a GPS Epoch in Microseconds

gpstime

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:

Best Answer

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.

Related Question