我从一个SQL数据库中提取日期，数据库将它们视为从午夜开始的日期，当我对它们使用toLocaleDateString()时，它正确地格式化了它们，但是在丢失一天之前没有格式化。
格式化前：2011-09-01T00:00:00
格式化后：8/31/2011
代码：
plan.dateReceived = new Date(plan.dateReceived).toLocaleDateString()+','+plan.dateReceived;为什么会这样呢？我可以做什么样的内联修复来让它正常工作呢？我也发现了another post that had a similar problem，但我不是100%相信这是一个时区问题。
3条答案
按热度按时间sg3maiej1#
如果您逐段运行代码，您会注意到
new Date('2011-09-01T00:00:00')生成类似Wed Aug 31 2011 20:00:00 GMT-0400 (EDT)的输出（我的计算机现在处于EDT）。这是因为（doc）：
假设时区的差异
给定日期字符串“March 7，2014”，解析（）假定本地时区，但是给定ISO格式，例如“2014-03-07”，它将假定UTC时区。因此，使用这些字符串生成的Date对象将表示不同的时刻，除非系统设置为UTC本地时区。这意味着看起来相等的两个日期字符串可能会产生两个不同的值，具体取决于要转换的字符串的格式（在ECMAScript第6版中更改了此行为，以便将两者都视为本地值）。
将其转换为语言环境日期字符串将使其转换为适合浏览器语言环境的字符串。Documentation表示“默认值是运行时的默认时区”。
如果要确保字符串使用UTC时间，请使用
2w2cym1i2#
我们在Google Chrome v87.0.4280 IOS上遇到了这个问题，但在使用相同浏览器的计算机上没有。
问题是时区字符串末尾不包含Z。
“Z”是DateTimes的一种独特的大小写形式。文字“Z”实际上是UTC时间的ISO 8601日期时间标准的一部分。当“Z”（祖鲁语）附加在时间的末尾时，它表示该时间是UTC，因此文字Z实际上是时间的一部分。
将Z追加到日期时间中解决了该问题。
hpcdzsge3#
上面的回答指出“这意味着看起来相等的两个日期字符串可能会产生两个不同的值，具体取决于要转换的字符串的格式（在ECMAScript第6版中更改了此行为，以便将两者都视为本地）。"。
这在写这篇文章的时候可能是正确的，但是看起来他们改变主意了，因为它不再说如果你点击的话。同样从在Chrome 109中的测试中，任何ISO 8601格式的日期，都被解析为UTC NOT local。和以前一样。ECMAScript ed 6和更高版本没有任何变化。更新的文本如下。希望这能节省一些时间。
给定非标准日期字符串“March 7，2014”，解析（）假定本地时区，但给定ISO 8601日历日期扩展格式的简化，例如“2014-03-07”，它将假定UTC时区。因此，根据支持的ECMAScript版本，使用这些字符串生成的Date对象可能表示不同的时间点，除非系统这意味着看起来相同的两个日期字符串可能会产生两个不同的值，具体取决于要转换的字符串的格式。