time - Ticks between Unix epoch and GPS epoch

Question

What is the number of one second ticks between Unix time epoch (01 Jan 1970) and GPS time epoch (06 Jan 1980)?

I have seen multiple answers from several sources on the web. One camp claims the answer is 315964800, the other claims it is 315964819. I always thought it was 315964800, but now am not so sure.

I just found my software baseline has been using 315964819 for the last eight years. I have a hard time understanding how it could have been 19 seconds off and no one noticed it when we integrated our embedded devices with other devices.

I think that whoever put 315964819 in the code baseline must have mistakenly used a TAI offset (19 seconds).

From what I understand, Unix time does not include leap seconds, which would indicate to me that 315964800 is the number of ticks between the two epochs. Then I think about how Unix time handles the leap second. It simply repeats the tick count when there is a leap second inserted, and there were 19 leap seconds inserted between 1970 and 1980... I start to wonder if the repeated ticks matter. I do not think so, but someone in this code's history thought so, and it seemed to work....

The long and short of it is I am about to change a constant set in the dark ages of this product that has to do with timing, which is important for the platform, from what it had been to what I believe is more accurate, and I wanted some sort of thumbs-up from more knowledgeable people than me.

Can someone authoritative please step in here?

315964800 camp

315964819 camp

Also note that I'm only asking about Unix epoch to GPS epoch. I'm pretty sure we've got leap seconds since GPS epoch covered appropriately.

Answer 1

The different values you stated are caused by mixing up the 1970 to 1980 offset with leap seconds.
The correct offset value is 315964800 seconds.

Explanation:

UTC and GPS time deviate (on average) every 18 months by one additional second. This is called a leap second, introduced in UTC time base, necessary to adjust for changes in the earth's rotation.

GPS Time not adjusted by leap seconds.

Currently (2013) there is an offset of 16s:
GPS Time-UTC = 16 seconds

Unix time is a time format not a time reference. It represents the number of milliseconds (or seconds) since 1.1.1970 UTC. Ideally your system time is synchronized with UTC by a TimeServer (NTP).

To convert, and get your offset, you should use a fixed offset: (6.1.1980 UTC - 1.1.1970 UTC)

and THEN add the current value of GPS to UTC deviation (currently 16s). E.g make that value configurable, or read the current offset from a GPS device (they know the difference between UTC and GPS Time)

The different values you stated are caused by mixing up 1970 to 1980 offset with leap seconds. Dont do that, handle them separately.

This java program:

SimpleDateFormat df = new SimpleDateFormat();
df.setTimeZone(TimeZone.getTimeZone("UTC"));

Date x = df.parse("1.1.1970 00:00:00");
Date y = df.parse("6.1.1980 00:00:00");

long diff = y.getTime() - x.getTime();
long diffSec = diff / 1000;

System.out.println("diffSec= " + diffSec);

Outputs this value:

diffSec= 315964800

So this is the correct offset between 1.1.1970 UTC and 6.1.1980 UTC where GPS Time began. Then you have to correct further 16 seconds which were introduced since 6.1.1980 and today, to calculate the GPS Time of a current UTC time.