浏览器、时区、Chrome 67 错误(历史时区更改)

IT技术 javascript date datetime browser
2021-01-11 13:39:08

我已将 Chrome 更新到 67 版本。我收到日期错误

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

微软边缘 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

火狐 60.0.1

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

-180

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

-180

铬 67.0.3396.62

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

-150

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

-180

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

-150 在 Chrome 67 中...

另一个例子(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)

请告诉我?

我能做什么 ?

形势很重要!我必须重写的所有代码...

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

2个回答

我将假设您在欧洲/莫斯科时区 - 鉴于您提供的输出,这似乎很可能。

根据 IANA 时区数据库,1900 年欧洲/莫斯科时区的偏移量为 +02:30:17 据推测,Chrome 正在四舍五入到 02:30 以避免亚分钟偏移,但据我所知,它正在返回适当的数据。至少根据 IANA 数据库,俄罗斯的偏移量在 1919 年首次变为整数小时。

可以说,您应该问为什么其他浏览器不这样做 - 但更有可能的是,您应该更改您的代码,使其不询问 1970 年之前的时区信息。IANA 数据库旨在提供 Unix 时代以后的准确数据;更早的任何事情都是“尽力而为”。理论文件

为每个此类位置记录 1970 年之前的时钟转换,因为大多数系统支持 1970 年之前的时间戳,并且如果在 1970 年之前的转换中省略数据条目,则可能会出现错误行为。但是,该数据库不是为需要准确处理所有过去时间的应用程序而设计的,也不足以满足所有应用程序的需求,因为记录 1970 年前民用计时的所有细节需要太多的努力和猜测。尽管数据库范围之外的一些信息收集在与数据库一起分发的文件后台中,但该文件不太可靠,并且不一定遵循数据库指南。

如果您在之前版本的 Chrome 中没有看到它,那么为什么您会在 Chrome 67 中看到它 - 我想知道 Chrome 是否刚刚开始捆绑 IANA 时区数据而不是使用操作系统数据。

这种行为是由 ECMA 规范的最新变化及其实现决定的(目前这些变化似乎仅在 Chrome 中实现) - 来源:chromium-review.googlesource.com/c/v8/v8/+/572148
2021-03-16 13:39:08

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

来自MDN 日期参考的注释

注意:由于浏览器的差异和不一致,强烈建议不要使用 Date 构造函数(和 Date.parse,它们是等效的)解析日期字符串。仅按惯例支持 RFC 2822 格式字符串。对 ISO 8601 格式的支持的不同之处在于,仅将日期字符串(例如“1970-01-01”)视为 UTC,而不是本地。

也许在您的代码中可以使用其他 Date 构造器,例如:

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