当我使用
在我的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没有：
-arne
答案 0 :(得分：1)
JavaScript Date对象专门遵循Unix Time的概念（尽管精度更高）。这是POSIX规范的一部分，因此有时称为“ POSIX时间”。它不算leap秒，而是假设每天恰好有86,400秒。您可以在section 20.3.1.1 of the current ECMAScript specification中阅读有关此内容的信息，该信息指出：
时间是使用UTC自1970年1月1日UTC以来以毫秒为单位的。在时间值上，leap秒将被忽略。假设每天正好有86,400,000毫秒。
JavaScript在这方面不是唯一的。这是绝大多数其他语言的工作方式，包括Python，Ruby，.NET，time_t在C语言中的典型实现以及许多其他语言。
因为您已更改系统以跟踪TAI而不是UTC，并且在系统上实现了date命令可以理解的a秒表，所以在系统time_t上却是'是Unix时间戳，而是伪装成Unix时间戳的TAI-based variant。仅仅因为date命令和其他基础函数可以识别这一点，并不意味着它会延续到计算机上的所有平台和运行时。
事实是，leap秒的不可预测特性使它们很难在API中使用。人们通常无法传递需要leap秒表才能正确解释的时间戳，并期望一个系统将其解释与另一个系统相同。例如，当示例时间戳记1483228826在系统上为2017-01-01T00:00:00Z时，在基于POSIX的系统或没有tables秒表的系统上，它将被解释为2017-01-01T00:00:26Z。因此它们不是便携式的。即使在具有完整更新表的系统上，也无法告知这些表将来将包含哪些内容（在6个月的IERS公告期之后），因此，我无法在没有将来可能会更改的风险的情况下生成将来的时间戳。 >
要明确-为了支持编程语言中的leap秒，实现必须尽力做到这一点，并且必须做出并非总是可以接受的折衷。尽管有例外，但总的立场是不支持它们-不是因为有任何颠覆或积极的对策，而是因为适当地支持它们要困难得多。
也就是说，如果您真的很在意JavaScript中的leap秒，那将给您带来希望。您可以将自己的想法添加到TC39 Temporal proposal中（我是其中的冠军之一）。这不会改变Date对象的行为-该对象已经烘焙了数十年。但是，我们正在使用JavaScript开发一组新的日期和时间标准对象，希望您能提供反馈和参与。在一个线程中，我们一直在考虑各种方法，leap秒可能成为问题#54的一部分。目前，我们尚未对基于TAI的系统进行过多思考。如果您有经验，请在此添加您的想法。请记住，我们需要在这与社区的一般需求之间取得平衡，但是我们希望您的想法。谢谢！
