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

Question

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

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。做数学看看。:-)

对于 UTC 的 2008 年 1 月 1 日，将 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 日以来的秒数表示，而不是毫秒。

我想你所看到的是时区的差异。您拥有的增量是 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