我电脑上的时区是UTC+3。我有以下 JavaScript 代码:
// date in UTC time zone
var date = new Date('2015-10-09T20:00:00.000Z');
var options = {year: "numeric", month: "2-digit", day: "2-digit"};
var output = date.toLocaleString('en-us', options);
在 IE 和 Chrome 中,此代码输出 10/09/2015
(即 2015 年 10 月 9 日),这是正确的,因为 20:00 UTC 是我时间的 23:00(现在仍然是 10 月 9 日) .
但是,在 Firefox 中,输出是 10/10/2015
(即 2015 年 10 月 10 日)——这就是问题所在。
如果我将初始日期/时间字符串更改为 2015-10-09T19:59:00.000Z
(比初始值早一分钟),Firefox 会给出正确的日期(2015 年 10 月 9 日) ).
为什么 Firefox 中的 toLocaleString()
方法会这样?
所有浏览器都安装在同一台计算机上。 Date.getTimezoneOffset()
在所有浏览器中返回 -180
。
最佳答案
您偶然发现了 Firefox 中的一个错误。我可以重现您的结果,并对其进行解释。
有多个时区使用 UTC+3 偏移量,但从您的结果我可以推断您设置为莫斯科时间。
在2014, Russia set all of its time zones back one hour .这将莫斯科的基准偏移量从 UTC+4 移动到 UTC+3。错误是 Firefox 似乎很困惑,并在其 toLocaleString
中使用旧的 +4 偏移量。函数,即使它正确识别了其他函数中的 +3 偏移量,例如 getTimezoneOffset
和 toString
.
您可以在尝试未通过此类更改的不同时区时看到这一点。在 Windows 上,我选择 "(UTC+03:00) Nairobi"
(其基础时区 ID 为 "E. Africa Standard Time"
)。它被定义为一直在 UTC+3 上的固定区域。
然后我关闭 Firefox 并将我的时区更改为 "(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)"
(其 ID 为“俄罗斯标准时间”)。然后我重新启动 Firefox 并做同样的测试:
如您所见,在第一个测试中,它得到了 toString
的正确答案。和 toLocaleString
, 但在第二次测试中它们是不同的。 toLocaleString
应用了错误的偏移量,到达 10 月 10 日午夜而不是 10 月 9 日正确的 23:00。
当然,当您使用格式化选项去除时间时,这更难看到,但它是相同的潜在错误。
此错误已报告给 Mozilla here .如果它对您很重要,您应该考虑对其进行投票。
至于做什么 - 一般来说,我目前不推荐 toLocaleString
功能。 ECMA-402 对此进行了定义,这很好,但它尚未得到广泛实现,而且这些实现在支持哪些选项方面有些不一致。几年后这可能是正确的方法,但现在我建议使用 moment.js相反。
关于javascript - 使用 toLocaleString() 方法 (Firefox) 将日期转换为本地时区,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33083936/