我从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%确信这是一个时区问题。
答案 0 :(得分:13)
如果你分段运行代码,你会注意到new Date('2011-09-01T00:00:00')
产生类似Wed Aug 31 2011 20:00:00 GMT-0400 (EDT)
的输出(我的电脑现在在EDT中)。
这是因为(doc):
假定时区的差异
给定日期字符串" 2014年3月7日",parse()假定当地时间 区域,但给定ISO格式,如" 2014-03-07"它会假设一个 UTC的时区。因此使用这些字符串生成Date对象 除非设置系统,否则将代表不同的时刻 UTC的当地时区。这意味着出现两个日期字符串 等效可能会导致两个不同的值,具体取决于格式 正在转换的字符串(此行为已更改) ECMAScript编辑6,以便将两者视为本地)。
将其转换为语言环境日期字符串会将其转换为适合浏览器语言环境的字符串。 Documentation表示"默认值是运行时的默认时区"。
如果您想确保字符串是UTC时间,请使用
new Date('2011-09-01T00:00:00').toLocaleDateString('en-US', {timeZone: 'UTC'})
答案 1 :(得分:0)
我们在谷歌浏览器 v87.0.4280 IOS 上遇到了这个问题,但在具有相同浏览器的计算机上没有遇到。
问题是时区字符串的末尾不包含 Z。
<块引用>“Z”是 DateTimes 的一种独特情况。字面的“Z”是 实际上是 UTC 时间的 ISO 8601 日期时间标准的一部分。什么时候 “Z”(祖鲁语)加在时间的末尾,表示那个时间 是 UTC,所以字面量 Z 是时间的一部分。
将 Z 附加到日期时间解决了问题。
new Date('2011-09-01T00:00:00Z').toLocaleDateString('en-US', {timeZone: 'UTC'})