浏览器,时区,Chrome 67错误

问题描述 投票:4回答:2

我已将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

Microsoft 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)

请告诉我?

我能做什么 ?

情况非常重要!我必须重写的所有代码......

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

javascript date datetime browser
2个回答
7
投票

我假设你在欧洲/莫斯科时区 - 这似乎可能是你提供的输出。

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

可以说你应该问其他浏览器为什么不这样做 - 但更有可能的是,你应该改变你的代码,以便在1970年之前不要求时区信息.IANA数据库的目的是从Unix时代开始提供准确的数据;任何早期的事情都是“尽力而为”。来自theory file

1970年之前的时钟转换被记录在每个这样的位置,因为大多数系统在1970年之前支持时间戳,并且如果在1970年之前的转换中省略了数据条目,则可能行为不端。然而,数据库的设计并不适用于需要在任何地方准确处理过去所有时间的应用程序,因为记录1970年以前民用计时的所有细节需要花费太多的精力和猜测。尽管数据库范围之外的某些信息是在与数据库一起分发的文件后区中收集的,但此文件不太可靠,并且不一定遵循数据库准则。

至于您在Chrome 67中看到这个问题的原因,如果您之前的Chrome版本没有看到它 - 我想知道Chrome是否刚刚开始捆绑IANA时区数据而不是使用操作系统数据。


0
投票

使用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));
© www.soinside.com 2019 - 2024. All rights reserved.