将自纪元以来的天数转换为自纪元以来的秒数

问题描述：

在我的新工作场所，他们将许多日期表示为“自纪元以来的日子”（我将在下文中称为DSE）。我遇到了将JavaScript从DSE转换为epoch以来的秒数（UNIX时间戳）的问题。这里是我的功能来进行转换：将自纪元以来的天数转换为自纪元以来的秒数

function daysToTimestamp(days) { 
    return Math.round(+days * 86400); 
}

举例来说，当我通过13878（期待，这代表2008年1月1日），我回来1199059200，并不1199098800如我所料。为什么？

我不明白你为什么四舍五入。你介意解释吗？ – 2008-09-26 00:31:24

也许因为他们也可以使用小数日期。 – 2008-09-26 00:38:38

注意：自纪元以来NON-LEAP秒。 pfranza的评论是真实的，但不是你问题的原因。 – 2008-09-26 00:40:45

答

这是因为它是既不时间的线性表示，也不UTC的真实表示（虽然它是经常被误认为两者），因为它代表了时间为UTC但它没有表示UTC闰秒的方式

http://en.wikipedia.org/wiki/Unix_time

答

1199059200代表2007年12月31日在UTC。示例Python会话：

>>> import time 
>>> time.gmtime(1199059200) 
(2007, 12, 31, 0, 0, 0, 0, 365, 0)

请记住，所有time_t值都是针对UTC的。 :-)你必须相应地调整你的时区。

编辑：既然你和我都在新西兰，这里是你如何可能已经得到了1199098800值：

>>> time.localtime(1199098800) 
(2008, 1, 1, 0, 0, 0, 1, 1, 1)

这是因为，在新的一年（在新西兰夏季），这里的时区是+1300。做数学，看看。 :-)

对于2008年1月1日在UTC，增加86400至1199059200，并获得1199145600.

>>> time.gmtime(1199145600) 
(2008, 1, 1, 0, 0, 0, 1, 1, 0)

答

的Unix时间（time_t的）自1970年1月1日不是毫秒秒表示。

我想象你所看到的是时区的差异。你拥有的三角洲是11个小时，你是如何获得预期价值的？

答

你应该86400000

1天相乘= 24小时*60分钟* 60秒*的1000毫秒= 86400000

答

由于86400分之1199098800= 13878.4583333333333（与3永远重复），而不是13878.0。它被整数存储为13878.0，因为它被存储为整数。如果你想看到它的差异，试试这个：.4583333333333 * 86400 = 39599.99999999712。即使这样做有些不正确，但这是差异来自的地方，因为1199098800-1199059200 = 35600。

将自纪元以来的天数转换为自纪元以来的秒数

相关推荐