我已经将Chrome更新为67版本。
新日期（1924,4,1,0,0,0,0）.getTime（）
返回-1441245724000
必须-1441249200000
如果毫秒（1000），秒（60），分钟（60）=== 0
getTime必须在最后至少给出5个零
最佳答案
只能有一个解释：您在乌克兰。
请允许我解释一下：
当将各个组件传递给Date构造函数时，这些值基于运行代码的计算机的本地时区。请记住，月份是从零开始的，new Date(1924,4,1,0,0,0,0)要求的是1924-05-01 00:00:00.000当地时间。.getTime()要求一个以UTC为基础的Unix时间戳（以毫秒为单位），因此存在从本地时间到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日之前在乌克兰的当地时间是太阳决定的，而不是政府决定的。至少-这是计算机拥有的最广为人知的信息。
关于javascript - Chrome 67中的getTime错误，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/50742739/