为什么 YYYY-MM-DD != YYYY/MM/DD [重复]答案

【问题标题】：Why is YYYY-MM-DD != YYYY/MM/DD [duplicate]为什么 YYYY-MM-DD != YYYY/MM/DD [重复]
【发布时间】：2015-12-02 07:25:56
【问题描述】：

在 Chrome 中，我们得到了一些奇怪的东西

> new Date("2014-01-01") - new Date("2014/01/01")
< 3600000

这是因为

new Date("2014-01-01")
Wed Jan 01 2014 01:00:00 GMT+0100 (CET)

同时

new Date("2014/01/01")
Wed Jan 01 2014 00:00:00 GMT+0100 (CET)

为什么“-”似乎增加了 1 小时？

【问题讨论】：

我的是加2，我是GMT+2
基本上我有两个不同的数据提要，我想检查一个提要的结束日期是否等于下一个提要的开始日期。一种具有一种格式，另一种具有另一种格式。所以当我开始检查1st - 2nd == 0 时，我没有得到任何True。我当然可以控制这一点，但它使生活更加复杂
你有没有看过这个：stackoverflow.com/q/15109894/2357233 可能对你有帮助
perhaps useful 好像斜线不符合规范？
48 票赞成欺骗。嘘

标签： javascript

【解决方案1】：

我认为差异是由Date.parse将UTC添加到一个字符串而不是另一个造成的，即：/ is not a legal separator in Date.parse() 这意味着UTC未添加到解析后的时间。因为'是合法的分隔符，所以解析后返回的时间加上UTC。

Date.parse 被new Date() 方法使用，它的实现是特定于浏览器的，我很惊讶这种事情不会经常出现。

Date.parse 的规范说：

根据字符串的内容，字符串可能被解释为本地时间、UTC 时间或其他时区的时间。该函数首先尝试根据日期时间字符串格式（15.9.1.15）中调用的规则解析字符串的格式。如果字符串不符合该格式，则函数可能会退回到任何特定于实现的启发式或特定于实现的日期格式。

所以我建议在解析之前手动添加时区，或者丢弃new Date() 返回的时间，但这可能会导致午夜等问题。最安全的做法是看看你是否可以获得来自两个系统的更具体格式的日期，以及时区信息。

【讨论】：

【解决方案2】：

引用自V8 source code。

这个函数的 cmets

bool DateParser::Parse(Vector<Char> str,
                       FixedArray* out,
                       UnicodeCache* unicode_cache)

接受与 Safari 兼容的 ES5 ISO 8601 日期时间字符串或旧日期。

ES5 ISO 8601 日期：
[('-'|'+')yy]yyyy[-MM[-DD]][THH:mm[:ss[.sss]][Z|(+|-)hh:mm]]
匹配两种格式的字符串（例如 1970-01-01）将是解析为 ES5 日期时间字符串 - 这意味着它将默认到 UTC 时区。如果遵循 ES5 规范，这是不可避免的。

破折号 (-) 是 Date 的正确表示法。

【讨论】：

【解决方案3】：

这是因为全球化。破折号 ( - ) 不是英文表示法 (GMT)。 Javascript 解析符号。尝试设置文化，然后使用破折号。

【讨论】：

其实-好像没问题，/不行