浏览器，时区，Chrome 67错误（历史时区更改）

Question

我已将 Chrome 更新至 67 版本。但我在日期上遇到了一个错误。

==============

Microsoft Edge 42.17134.1.0

new Date("1900-01-01T00:00:00").getTimezoneOffset() 

-180

new Date("2018-05-30T00:00:00").getTimezoneOffset()

-180

微软 Internet Explorer 11.48.17134.0

new Date("1900-01-01T00:00:00").getTimezoneOffset() 

-180


new Date("2018-05-30T00:00:00").getTimezoneOffset() 

-180

Mozilla Firefox 60.0.1

new Date("1900-01-01T00:00:00").getTimezoneOffset() 

-180

new Date("2018-05-30T00:00:00").getTimezoneOffset() 

-180

Chrome 67.0.3396.62

new Date("1900-01-01T00:00:00").getTimezoneOffset() 

-150

new Date("2018-05-30T00:00:00").getTimezoneOffset()

-180

======================

-Chrome 67中的-150...

另一个示例（Chrome 67）：

new Date("1900-01-01T00:00:00");

Mon Jan 01 1900 00:00:00 GMT+0230 (Moscow Standard Time)

======================

Chrome 67开始，时区显示错误（+0230，原本应该是+0300）。

请告诉我怎么办？

有什么解决方法吗？

这个问题非常重要！我必须重新编写所有代码...

======================

- Alexey

---

历史日期、时间和时区如果要进行准确的计算，是非常复杂的。尽管今天它们仍然有些混乱，但比过去简单得多。你不能期望一个JavaScript实现包含所有日期、所有时区和地区的所有偏移量（特别是在JavaScript中，“locale”实际上是一个语言代码，而不是一个位置）。如果你需要这个功能，使用一个带有适当的基于位置（而不是语言）的准确偏移量数据库的库，例如IANA时区数据库。 - RobG

RobG，谢谢您！您能说出一些适合使用数据库的JavaScript库吗？ - Alexey

请求外部资源不在此处讨论范围之内。您可以从 moment timezone 开始，它是 moment.js 的扩展，并使用来自 IANA 时区数据库的数据。然而，我不知道历史数据支持有多少年份，以及数据的广度和准确性如何。 - RobG

谢谢！我已经使用momentjs适应了代码。但是我遇到了另一个问题。客户端已经学习了时区。对于客户端上的“1900-01-01T00:00:00+02:30”没有问题，但是我在处理来自服务器的日期“1900-01-01T00:00:00+03:00”时出现了问题。它变成了1899年，减去了30分钟！我该如何解决？我已经在Chrome 67上学习了客户端，那么客户端将如何在其他浏览器上工作呢？请原谅我的英语！ - Alexey

@Alexey：那是一个单独的问题，你需要在一个新的问题中提供更多上下文信息。RobG和我已经解释了为什么您可能会看到不同的偏移量，特别是对于很久以前的日期/时间值。这就是这个问题的所在。如果您想知道如何最好地处理它，您需要提供关于您正在尝试做什么以及您拥有哪些代码的更多信息。 - Jon Skeet

Answer 1

我假设你处于欧洲/莫斯科时区——根据你提供的输出，这似乎很可能是正确的。1900年，欧洲/莫斯科时区偏移量为+02:30:17，根据IANA时区数据库。Chrome可能会将其四舍五入为02:30，以避免出现次分钟偏移，但据我所见，它返回了适当的数据。至少根据IANA数据库，在1919年，俄罗斯的偏移量首次成为整数小时。可以说，你应该问为什么其他浏览器没有这样做，但更有可能的是，你应该修改代码，不要在1970年之前请求时区信息。IANA数据库旨在从Unix纪元开始提供准确的数据；任何早期的数据都是尽力而为。来自理论文件的内容。

在每个这样的位置记录1970年之前的时钟转换，因为大多数系统支持1970年之前的时间戳，并且如果省略了1970年之前的转换数据条目，则可能会出现问题。然而，该数据库并不是为需要准确处理所有过去时间的应用程序设计的，因为记录所有有关1970年之前的民用时间的细节需要付出太多的努力和猜测。虽然一些超出数据库范围的信息在一个名为backzone的文件中收集，该文件与数据库一起分发，但该文件不够可靠，并且不一定遵循数据库指南。

至于为什么您在Chrome 67中看到了这个问题，而以前版本的Chrome没有 - 我想知道Chrome是否开始捆绑IANA时区数据而不是使用操作系统数据。

- Jon Skeet

---

这种行为是由ECMA规范的最近变更及其实现所决定的（似乎目前只在Chrome中实现了这些变更）- 来源：https://chromium-review.googlesource.com/c/v8/v8/+/572148 - Krzysztof Grzybek

Answer 2

我在使用new Date("..")构造函数时遇到了一些类似的问题（也因为Chrome版本更改）。

来自MDN Date Reference的一条注释：

注意：强烈不建议使用Date构造函数（和Date.parse，它们是等效的）解析日期字符串，因为浏览器之间存在差异和不一致性。 RFC 2822格式字符串的支持仅基于约定。 ISO 8601格式的支持有所不同，因为仅包含日期的字符串（例如“1970-01-01”）被视为UTC而不是本地时间。

也许在您的代码中可以使用其他Date构造函数，例如：

 new Date(Date.UTC(96, 1, 2, 3, 4, 5));

- powerpete