Unix时代和GPS时代之间的嘀嗒声 [英] Ticks between Unix epoch and GPS epoch

问题描述

Unix时间纪元（1970年1月1日）和GPS时间纪元（1980年1月6日）之间的秒数是多少？

来自网络上的多个来源。一个阵营声称答案是 315964800 ，另一个阵营声称 315964819 。我一直认为它是315964800，但现在我不太确定。

我刚刚发现我的软件基线在过去八年中一直使用315964819。我很难理解如何将它关闭19秒，当我们将我们的嵌入式设备与其他设备集成时，没有人注意到它。

我认为无论谁把315964819在代码基线中必须错误地使用TAI偏移量（19秒）。

据我所知，Unix时间不包括闰秒，这表明我315964800是两个时代之间的蜱虫数量。然后我想到Unix时代如何处理闰秒。它只是在插入闰秒时重复滴答计数，并且在1970年到1980年之间插入了19次闰秒......我开始怀疑重复滴答是否重要。我不这么认为，但是在这段代码的历史中有人认为是这样，而且它似乎工作....

这是我即将在这个产品的黑暗时代改变一个固定的时间，这个时间对于平台来说很重要，这个时间对于我认为更准确的时间来说是很重要的，我想要更多的知识更多的赞赏人比我。

有人权威请在这里介绍一下吗？

315964800阵营

315964819阵营

另外请注意，我只询问关于GPS时代的Unix纪元。我相当肯定，自从GPS时代恰当地覆盖以来，我们已经有了飞跃。 你说的不同值是由将1970年至1980年的偏移量与闰秒混合。

正确的偏移值为315964800秒。

解释：

UTC和GPS时间每隔18个月偏差一次（平均）一秒。
这被称为闰秒，以UTC时间基准引入，这是调整地球自转变化所必需的。

GPS时间未经调整闰秒。目前（2013年）有16秒的偏移量：

GPS Time-UTC = 16秒

Unix时间是一种时间格式，不是时间参考。
它表示自UTC19.7.1970以来的毫秒数（或秒）。
理想情况下，您的系统时间通过TimeServer（NTP）与UTC同步。

要转换并获得偏移量，您应该使用固定偏移量:( UTC时间1997年6月1日 - 1997年1月1日）

然后将GPS当前值添加到UTC偏差（当前16秒）。
例如：设置该值，或者读取GPS设备的当前偏移量（他们知道UTC和GPS时间之间的差异）

您声明的不同值是由1970年到1980年的闰秒混合造成的。
不这样做，分别处理它们。

这个java程序：

  SimpleDateFormat df = new SimpleDateFormat（）; 
 df.setTimeZone（TimeZone.getTimeZone（UTC））; 
 
日期x = df.parse（1.1.1970 00:00:00）; 
日期y = df.parse（6.1.1980 00:00:00）; 
 
 long diff = y.getTime（） -  x.getTime（）; 
 long diffSec = diff / 1000; 
 
 System.out.println（diffSec =+ diffSec）; 
  

输出此值：

diffSec = 315964800

所以这是在UTC时间1.1.1970 UTC和6.1.1980 UTC之间的正确偏移量，其中GPS时间开始了。
然后，你必须进一步校正自从6.1.1980和今天以来引入的16秒，以计算当前UTC时间的GPS时间。

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.

解决方案

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.

这篇关于Unix时代和GPS时代之间的嘀嗒声的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！