在我的新工作场所中，它们表示很多日期为"自纪元以来的天数"(以下我将其称为DSE)。我遇到了JavaScript的问题，即从epoch(UNIX时间戳)转换为DSE到秒。这是我执行转换的功能：

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

举例来说，当我通过13878(预计代表2008年1月1日)时，我会得到1199059200，而不是我期望的1199098800。为什么？

解决方案

这是因为它既不是时间的线性表示形式，也不是UTC的真实表示形式(尽管经常会误以为两者)，因为它表示的时间都是UTC，但无法表示UTC leap秒

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

因为1199098800/86400 = 13878.4583333333333(其中3个永远重复)，而不是13878.0。由于将其存储为整数，因此四舍五入为13878.0。如果要查看它的不同之处，请尝试以下操作：.4583333333333 * 86400 = 39599.99999999712. 即便如此，它也会稍有不正确，但这就是差异的来源，如1199098800-1199059200 = 35600。