在我的新工作场所，它们将很多日期表示为“自纪元以来的天数”（我将在下文中将其称为 DSE）。我在将 JavaScript 从 DSE 转换为自纪元以来的秒数（UNIX 时间戳）时遇到了问题。这是我进行转换的功能：
function daysToTimestamp(days) {
return Math.round(+days * 86400);
}
例如，当我传入 13878（预计这代表 2008 年 1 月 1 日）时，我得到了 1199059200，而不是我预期的 1199098800。为什么？
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)
这是因为它既不是时间的线性表示，也不是 UTC 的真实表示（尽管它经常被误认为两者），因为它表示的时间是 UTC，但它无法表示 UTC 闰秒
Unix 时间 (time_t) 以 1970 年 1 月 1 日以来的秒数表示，而不是毫秒。
我想你所看到的是时区的差异。您拥有的增量是 11 小时，您如何获得预期值？
因为 1199098800/86400 = 13878.4583333333333（3 永远重复），而不是 13878.0。它被四舍五入到 13878.0，因为它被存储为整数。如果你想看看它的不同之处，试试这个：.4583333333333*86400 = 39599.99999999712。即使这样也有点不正确，但这就是差异的来源，如 1199098800-1199059200=35600。
你应该乘以 86400000
1 天 = 24 小时 * 60 分钟 * 60 秒 * 1000 毫秒 = 86400000