javascript中的闰秒在哪里？

Question

当我使用时

• custom zoneinfo file for TAI 或 /usr/share/zoneinfo-leaps 和
• 修改后的 NTP 客户端（目前它只增加 27 秒；并等待大约 1 秒关闭的时间戳）

在我的 ArchLinux 机器上， 系统时间表现良好：

> date
Tue Oct 23 17:10:34 TAI 2018
> date -d @1483228827
Sun Jan  1 00:00:00 UTC 2017
> date -d @1483228826
Sat Dec 31 23:59:60 UTC 2016
> date -d @1483228825
Sat Dec 31 23:59:59 UTC 2016

但是：JavaScript 没有：

• test page

• screenshot

  1. Mozilla/Firefox/Javascript 是否使用自己的 zoneinfo 文件 什么地方？
  2. 我该如何解决？
  3. 甚至websites dedicated to time 似乎都没有正确...还是我错过了什么？

-阿恩

Answer 1

JavaScript Date 对象特别遵循Unix Time 的概念（尽管精度更高）。这是 POSIX 规范的一部分，因此有时称为“POSIX 时间”。它不计算闰秒，而是假设每天正好有 86,400 秒。您可以在section 20.3.1.1 of the current ECMAScript specification 中阅读有关此内容的信息，其中指出：

自 1970 年 1 月 1 日 UTC 以来，时间在 ECMAScript 中以毫秒为单位进行测量。在时间值中，闰秒被忽略。假设每天正好有 86,400,000 毫秒。

JavaScript 在这方面并不是独一无二的。这是绝大多数其他语言所做的，包括 Python、Ruby、.NET、time_t 在 C 中的典型实现等等。

因为您已将系统更改为跟踪 TAI 而不是 UTC，并且在您的系统上实现了 date 命令可以理解的闰秒表，所以在您的系统上 time_t 不是 Unix 时间戳，而是伪装成 Unix 时间戳的 TAI-based variant。仅仅因为 date 命令和其他底层函数能够识别这一点，并不意味着它可以应用于您机器上的所有平台和运行时。

事实上，闰秒的不可预测性使得它们很难在 API 中使用。人们通常无法传递需要正确解释闰秒表的时间戳，并期望一个系统将它们解释为与另一个系统相同。例如，虽然您的示例时间戳 1483228826 在您的系统上是 2017-01-01T00:00:00Z，但在基于 POSIX 的系统或没有闰秒表的系统上，它将被解释为 2017-01-01T00:00:26Z。所以它们不是便携式的。即使在具有完整更新表的系统上，也不知道这些表将来会包含什么（在 6 个月的 IERS 公告期之后），因此我无法生成未来的时间戳而不会有最终更改的风险。

要明确 - 要在编程语言中支持闰秒，实现必须不遗余力地做到这一点，并且必须做出不总是可以接受的权衡。虽然也有例外，但一般的立场是不支持它们——不是因为任何颠覆或积极的反制措施，而是因为正确地支持它们要困难得多。

也就是说，如果您真的关心 JavaScript 中的闰秒，那么您就有希望了。您可以将您的想法添加到TC39 Temporal proposal（我是其中的冠军之一）。这不会改变 Date 对象的行为 - 已经烘焙了几十年。但是我们正在为 JavaScript 中的日期和时间开发一组新的标准对象，并且希望您的反馈和参与。在问题#54 中有一个线程，我们一直在考虑闰秒可能成为其中一部分的各种方式。目前，我们还没有对基于 TAI 的系统进行过多思考。如果这是您有经验的领域，请在此处添加您的想法。请记住，我们需要在这与社区的一般需求之间取得平衡，但我们希望得到您的想法。谢谢！