TL;DR
new Date 和 Date.parse 在花样化某些日期字符串的时刻，时区具有不确定性，最好用 moment.js 这类东西去处置惩罚。
不确定的日期字符串
事变的劈头是客户跟我说网页上的某个日期老是比现实日期少一天。经由一步步 debug 后发现问题在此：
js// 客户时区为美国东部时区夏令时 new Date("2015-03-31") // Mon Mar 30 2015 20:00:00 GMT-0400 (EDT)
明显写的 31 号，为何天生的对象是 30 号的？由于 new Date 把它剖析为 2015-03-31 00:00:00 ，时区为 UTC 。美国东部时区是减 4 小时的，于是就变成了前一天 20:00:00 。
那末 new Date 传入的时候字符串有无规律可循呢？
杂沓的规律
new Date 和 Date.parse 运用的是一样的剖析规律，只是一个返回 Date object 另一个返回毫秒数。为了轻易检察效果，以下例子只用 new Date 。但请记着它们遵照一样的规律。
new Date 能够传入一个日期字符串来天生对象的，官方划定日期字符串须要相符 RFC2822 或许 ISO8601 的花样。拿上面的日期举个例子，前者能够写成 “Mar 31 2015” 后者能够写成 “2015-03-31” 。
假如日期字符串不相符这两种规范，new Date 对效果概不负责……
不过就算相符规范了，效果照样有点差别的。看几个例子：
jsnew Date("Mar 31 2015") // Tue Mar 31 2015 00:00:00 GMT-0400 (EDT) new Date("2015-03-31") // Mon Mar 30 2015 20:00:00 GMT-0400 (EDT)
RFC2822 的花样假如不带时区，new Date 会当作当地时区处置惩罚，而 ISO8601 花样则会当作 UTC 时区处置惩罚。
是有点绕人，但只需记着这个规律不就完了吗？骚年你太无邪了…… 由于 ES6 草案为了简化这类状况，划定一切不带时区的字符串都默以为当地时区。注重这是草案，所以效果你懂的。
解决方案
一种解决方案是每次花样化日期都严厉指定时区，以防备种种么蛾子状况涌现，比方：
jsnew Date("2015-03-31T00:00:00-04:00") // Tue Mar 31 2015 00:00:00 GMT-0400 (EDT)
不过鉴于人都是懒散的，这类状况交给东西做更靠谱，比方 moment.js 。
jsmoment("2015-03-31").toDate()
