我已经看到来自网络上的多个来源的多个答案.一个阵营声称答案是315964800,另一个声称是315964819.我一直认为是315964800,但现在不太确定.
我刚刚发现我的软件基线在过去八年一直使用315964819.当我们将嵌入式设备与其他设备集成在一起时,我很难理解19秒的关闭状态,没有人注意到.
我认为把315964819放在代码基线中的人必须错误地使用TAI偏移量(19秒).
从我的理解,Unix时间不包括闰秒,这将告诉我,315964800是两个纪元之间的刻度数.然后我想想Unix时间如何处理闰秒.当插入闰秒时,它只会重复刻度计数,并且在1970年至1980年之间插入了19个闰秒…我开始怀疑重复的蜱虫是否重要.我不这么认为,但是这个代码的历史中有人认为是这样,似乎工作….
我的这个短短的一段时间我将要改变这个产品的黑暗时代的一个常数,这与时间有关,这对于平台很重要,从现在到我所相信的更准确,我想要从更多知识渊博的人那里得到一些竖起大拇指.
有人有权威请登入吗？
还要注意的是,我只是问到关于Unix的时代到GPS的时代.我相信自己的GPS时代已经适当地覆盖了我们的闰秒.
正确的偏移值为315964800秒.
说明：
UTC和GPS时间每18个月平均(平均)减一秒.
这被称为闰秒,以UTC时基介绍,需要调整地球旋转的变化.
GPS时间未被闰秒调整.
目前(2013)有16s的抵消：
GPS时间UTC = 16秒
Unix时间是时间格式不是时间参考.
它表示自1.1.1970 UTC以来的毫秒数(或秒).
理想情况下,您的系统时间与UTC由TimeServer(NTP)同步.
要转换并获得您的偏移,您应该使用固定的偏移量：(6.1.1980 UTC – 1.1.1970 UTC)
然后将GPS的当前值添加到UTC偏差(当前为16s).
例如,可以配置该值,或从GPS设备读取当前偏移量(他们知道UTC和GPS时间之间的差异)
你所说的不同的价值是由1970年至1980年的闰秒混合造成的.
不要这样做,单独处理它们.
这个java程序：
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);
输出此值：
diffSec= 315964800
所以这是GPS时间开始之间1.1.1970 UTC和6.1.1980 UTC之间的正确偏移.那么你必须更正16秒,这是6.1.1980和今天介绍的,以计算当前UTC时间的GPS时间.
