我已将Chrome更新为67版。
新日期（1924,4,1,0,0,0,0）.getTime（）
返回-1441245724000
必须-1441249200000
如果毫秒（1000），秒（60），分钟（60）=== 0 getTime必须在最后给出至少5个零
答案 0 :(得分：3)
只能有一种解释： 你在乌克兰。
请允许我解释一下：
将单个组件传递给Date构造函数时，这些值基于运行代码的计算机的本地时区。请记住，月份为零，new Date(1924,4,1,0,0,0,0)要求1924-05-01 00:00:00.000 当地时间。
.getTime()要求以毫秒为单位的Unix时间戳，它基于UTC - 因此存在从本地时间到UTC的隐式转换。因此，运行此代码的任何人都会根据自己的时区获得不同的结果。
时区是一项相对现代的发明。它们并不总是存在于我们今天使用它们的方式中。大多数计算机保留的有关时区的数据来自the IANA time zone database。在此数据中，对于大多数时区，最早的条目是基于与用于识别时区的城市相关的纬度和经度的太阳local mean time（LMT）。
在这种情况下，您的值-1441245724000会转换为1924-04-30 21:57:56 UTC。由于它是从当地午夜时间推导出来的，因此通过数学计算 - 当地时间与UTC的偏差必须为+02:02:04。
TZDB中唯一一个LMT值为+02:02:04的时区是Europe/Kiev，as shown here。由于我不确切的原因，TZDB还从1880年到1924年分配了缩写KMT（基准平均时间）。
至于为什么你会在较新版本的Chrome上看到这一点 - 旧版本很可能没有考虑整个TZDB，但过去曾在某个时候截断过它。实际上，ECMAScript 5.1标准过去只需要应用当前时区规则，就像它一直有效一样。这已在ECMAScript 6中删除，现在大多数浏览器都使用对所提供的时间戳有效的正确规则。
TL; DR ：1924年5月1日之前在乌克兰的当地时间由太阳决定 - 而不是由政府决定。至少 - 这是您的计算机最知名的信息。