Question

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

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

举例来说，当我通过13878（期待这代表2008年1月1日）时，我得到了1199059200，而不是我期望的1199098800。为什么呢？

Answer 1

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)

Answer 2

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

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

Answer 3

Unix时间（time_t）以1970年1月1日以秒为单位表示，而不是毫秒。

我想你所看到的是时区的差异。您拥有的delta是11个小时，您是如何获得预期值的？

Answer 4

因为1199098800/86400 = 13878.4583333333333（永远重复3次），而不是13878.0。它被舍入到13878.0，因为它被存储为整数。如果你想看到它的差异，试试这个：.4583333333333 * 86400 = 39599.99999999712。即使这样也会略微不正确，但这就是差异的来源，如1199098800-1199059200 = 35600。

Answer 5

您应该乘以86400000

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

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

5 个答案: