我的数据时间戳有2种格式，其中3F536DDA -> 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
答案 0 :(得分：3)
嗯，这些看起来就像十六进制数字，这可能是自1970年1月1日UTC以来的秒数。
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日UTC以来，其他数字看起来像十进制微秒，但它们不等于其他数字：
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
答案 1 :(得分：0)
你会认为它就像在GPS时代（1980年1月6日午夜）和Unix时代（1970年1月1日午夜）之间的差异一样容易。这个答案会让你接近但不准确，因为GPS时间没有考虑到闰秒。自1980年以来，每增加一次闰秒，计算都会有所偏差。
我写了一个你可以在这里使用的帮助库：https://github.com/davidcalhoun/gps-time.js
如果您有兴趣，算法基本上是这样的： 1）从GPS转换为Unix时代 2）对于任何给定日期，确定已添加的闰秒数 3）根据已经过了多少闰秒进行时间调整
为了能够在任意时间内工作，包括过去的时间，这基本上需要在所有精确的闰秒时间内遍历查找表。
重要的是，它还意味着为防止漂移，代码需要在将来每次添加闰秒时更新。幸运的是，它就像在查找表中添加闰秒一样简单！