1

我有两种格式的时间戳数据，where3F536DDA -> 1378397085768000和3F52C3C3 -> 1378353476238000. 我似乎无法弄清楚是什么格式3F536DDA，也不知道如何将其转换为有问题的时代。任何帮助，将不胜感激！

更新

我发现了这个：

自 1980 年 1 月 6 日格林威治标准时间 00:00:00 以来以秒为单位的修复时间的 8 位十六进制表示。

这似乎是 GPS 时间。

我可能在这里的转换中遗漏了一些东西，我只是减去了 1980 年 1 月 6 日和 1970 年 1 月 1 日之间的差异......

time = (1378397085 - 315964800)

console.log '3F536DDA' # What I expected
console.log time.toString(16) # What I get: 3F536D1D
4

2 回答 2

3

好吧，这些看起来就像十六进制数字，自 1970 年 1 月 1 日以来的秒数。

3F536DDA hex == 1062432218 dec == Mon, 01 Sep 2003 16:03:38 GMT
3F52C3C3 hex == 1062388675 dec == Mon, 01 Sep 2003 03:57:55 GMT

自 1970 年 1 月 1 日以来，其他数字看起来像十进制微秒，但它们不等于其他数字：

1378397085768000 == Thu, 05 Sep 2013 16:04:45 GMT
1378353476238000 == Thu, 05 Sep 2013 03:57:56 GMT

如果这些不是您想到的日期，那么还有其他一些时期。例如，如果它们起源于 Microsoft Windows，它们肯定会有所不同。

你从哪里弄来的？这些知识将有助于他们的解释。

更新

既然您说它们基于 1980 年 1 月 6 日的纪元，那么您可以执行以下操作：

var d = new Date(Date.UTC(1980,0,6) + parseInt('3F536DDA', 16) * 1000);
d.toISOString();  // 2013-09-05T16:03:38.000Z

或者更好的是，使用moment.js

var m = moment.utc("1980-01-06").add('seconds', parseInt('3F536DDA', 16));
m.toISOString();  // 2013-09-05T16:03:38.000Z
于 2013-09-09T03:31:07.977 回答
0

你会认为它就像区分 GPS 纪元（1980 年 1 月 6 日午夜）和 Unix 纪元（1970 年 1 月 1 日午夜）一样简单。这个答案会让你接近但不准确，因为 GPS 时间不考虑闰秒。自 1980 年以来每增加一个闰秒，计算就会出现偏差。

我写了一个帮助库，你可以在这里使用：https ://github.com/davidcalhoun/gps-time.js

如果您有兴趣，该算法本质上是这样的：1）从 GPS 转换为 Unix 纪元 2）对于任何给定日期，确定已添加的闰秒数 3）根据已过去的闰秒数进行时间调整

为了使其适用于任意时间，包括过去的时间，这基本上需要遍历查找表，其中包含闰秒的所有确切时间。

重要的是，这也意味着为了防止漂移，以后每次添加闰秒时都需要更新代码。幸运的是，它就像在查找表中添加闰秒一样简单！

于 2017-07-11T22:44:01.790 回答