JavaScript日期专用格式保证在现代浏览器中被解释为本地时间

Question

我正在寻找一种日期格式（只有年、月和日，没有时间组件），当传递给JavaScript中的date（）构造函数时，它将被保证在所有合理现代的浏览器中被解释为本地时间。

(3-letter English month abbreviation) (2-digit date) (4-digit year)格式似乎有效。当我在Chrome中的英语系统上执行new Date('Apr 01 2015')时，我的机器位于东部时区，我会返回Wed Apr 01 2015 00:00:00 GMT-0400 (Eastern Daylight Time)，这正是我想要的。

但是，我不确定无论浏览器和浏览器/OS区域设置/语言如何，是否都能保证以相同的方式解释(3-letter English month abbreviation) (2-digit date) (4-digit year)格式。

这种格式在不同的（相当现代的）浏览器和地区之间会以相同的方式工作吗？如果没有，那么还有其他格式可以工作吗？

请注意，ISO-8601没有回答这个问题。ISO-8601仅限日期的字符串被解释为UTC，而不是本地时间，因此new Date('2015-04-01')被解释为Tue Mar 31 2015 20:00:00 GMT-0400 (Eastern Daylight Time)，即4月1日变成3月31日，这不是我想要的

Answer 1

我正在寻找一种日期格式（只有年、月和日，没有时间组件），当传递给JavaScript中的date（）构造函数时，它将保证在所有合理现代的浏览器中被解释为本地时间。

没有。在实践中，有许多格式可以由所有使用中的浏览器可靠地解析，但ECMA-262不要求ECMAScript实现支持这些格式。

ES5和ECMAScript 2015中指定了一种格式，即ISO 8601版本，但在ES5中，不带时区的日期将被视为UTC，在ECMAScript2015中被视为"本地"。

但这被实现者视为"破坏网络"，因此，尽管一些浏览器实现了一段时间，但它们现在已经恢复到ES5行为，并将丢失的时区视为UTC。

格式上的一个小变化，如将分隔符从"-"更改为"/"，会导致恢复到依赖于实施的行为，并可能导致日期被视为UTC或本地日期（尽管大多数人似乎将2015/12/17视为本地日期）。

因此，如果您想要保证，则没有。然而，如果您准备编写一个2行函数，则可以根据您喜欢的时区可靠地解析类似ISO8601的字符串。如果您希望将其视为本地（即设置为00:00:00并根据系统设置偏移），则：

function parseISOLike(s) {
    var b = s.split(/D/);
    return new Date(b[0], b[1]-1, b[2])
}
document.write(parseISOLike('2015-12-17'));

将完成这项工作（不检查有效值），并允许分隔符为任何非数字，因此2015/12/17、2015-12-17和2015.12.17都将被正确解析。

编辑

由于马特·约翰逊的投入，以上部分内容已被编辑。