为什么是YYYY-MM-DD！= YYYY / MM / DD
在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小时的时间？
我认为这种差异是由Date.parse将UTC添加到一个string而不是另一个string造成的，即： /不是Date.parse（）中的合法分隔符，意味着UTC不会被parsing。 由于'是合法的分隔符，因此会对其进行parsing，然后将UTC添加到返回的时间。
Date.parse被new Date()方法使用，它的实现是浏览器特定的，我很惊讶这种事情不会经常出现。
Date.parse的规范说：
根据string的内容，string可能被解释为本地时间，UTC时间或某个其他时区的时间。 函数首先尝试根据date时间string格式（15.9.1.15）中调出的规则来parsingstring的格式。 如果string不符合该格式，该函数可能会回退到任何特定于实现的启发式或实现特定的date格式。
所以我build议在分析之前手动添加时区，或者丢弃new Date()返回的时间，但是这可能会导致午夜等问题。最安全的方法是查看是否可以获取date来自两个系统的更具体的格式，以及时区信息。
从V8源代码引用。
来自这个函数的意见
bool DateParser::Parse(Vector<Char> str, FixedArray* out, UnicodeCache* unicode_cache)
接受ES5 ISO 8601date时间string或与Safari兼容的旧版date。
ES5 ISO 8601date：
[('-'|'+')yy]yyyy[-MM[-DD]][THH:mm[:ss[.sss]][Z|(+|-)hh:mm]]一个匹配两种格式的string（例如1970-01-01）将被parsing为ES5date时间string – 这意味着它将默认为UTC时区。 如果遵循ES5规范，这是不可避免的。
破折号（ – ）是Date正确表示法。
这是因为全球化。 破折号（ – ）不是英文符号（GMT）。 Javascriptparsing符号。 尝试设置文化，然后使用破折号。
