我遇到了一个超级奇怪的事情，显然是 IE 特定的toLocaleString关于日期。
在 IE 控制台窗口中：
new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
"8/28/2014 1:51:09 PM"
现在，手动将该字符串作为字符串键入，并将其与方法返回的内容进行比较：
"8/28/2014 1:51:09 PM" === new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
false
有谁知道为什么 IE 中会发生这种情况？ Chrome 中不会出现这种情况。
更新：更多示例：
new Date("8/28/2014 1:51:09 PM")
[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time)[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time)
new Date(new Date("2014-08-28T20:51:09.9190106Z").toLocaleString())
[date] Invalid Date[date] Invalid Date
首先，了解一些背景知识：IE11 实现了重新定义的 ECMA-402 ECMAScript 国际化 APIDate.prototype.toLocaleString（也toLocaleDateString and toLocaleTimeString）作为调用format on Intl.DateTimeFormat。像这样，d.toLocaleString()相当于
Intl.DateTimeFormat(undefined, {
year: 'numeric',
month: 'numeric',
day: 'numeric',
hour: 'numeric',
minute: 'numeric',
second: 'numeric'
}).format(d)
您可能认为这非常明确，但浏览器在支持哪些格式以及构成该格式的字符方面有很大的余地。这是设计使然 - 对于全球所有区域设置和语言，指定这一点将是相当繁重的，并且很难保持最新状态。因此，您不能指望能够比较以下结果toLocaleString跨浏览器，甚至期望同一个浏览器在不同版本之间继续提供相同的结果。随着底层区域设置数据的变化（可能是因为本地自定义已更改，或者有更多数据可用，或者添加了更好的格式），从此 API 返回的格式也会发生变化。
由此得出的结论是，您应该尽量不要依赖于比较toLocaleString在您的应用程序中具有某些静态值的 API。此外，给定日期d, Date.parse(d.toLocaleString())有时可能有效，但其他则不起作用，具体取决于区域设置，因此最好也避免这种情况。
话虽如此，en-US 相对稳定，并且大多数浏览器（目前）都同意基本格式是什么。但是，IE 在日期周围插入双向控制字符。这是设计使然，因此输出文本在与其他文本连接时将正确流动。当混合 LTR 和 RTL 内容（例如将格式化的 RTL 日期与 LTR 文本连接）时，这一点尤其重要。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
