对于我的WebApp，我正在使用Jest编写单元测试，而我的开发环境是IntelliJ Ultimate 2018.1.。
在单元测试中，我需要从字符串创建Date（）。我的问题是，当我与同事共享此单元测试时，它不起作用，因为Date（String）返回的日期不同（他使用的是相同的开发环境）。
例如，在我的环境中，当我执行新的Date（“ 2018-05-12T 19:00:00 ”）时，我得到了2018年5月12日星期六 19:00:00 GMT + 0200（浪漫的夏令时）
当我的同事执行完全相同的代码行时，他将在2018年5月12日星期六得到 21:00:00 GMT + 0200（巴黎，马德里（heure d'été））
当我在日期末尾添加Z时，例如新的Date（“ 2018-05-12T19：00：00Z”），我将获得2018年5月12日星期六 21:00:00 GMT +0200（浪漫的夏令时），他与2018年5月12日星期六的日期相同。 21:00:00 GMT + 0200（巴黎，马德里（Heure d'été））
为什么使用新的Date（“ 2018-05-12T19：00：00”）会得到2个小时的差异？我们在同一时区。
感谢您的帮助！
答案 0 :(得分：0)
旧的ECMAScript 5.1规范在§15.9.1.15中说：
...缺少时区偏移的值为“ Z”。
这意味着，如果您未指定偏移量，则会假设您的意思是UTC。
请注意，由于这与ISO-8601的说法相反，因此ECMAScript 2015（6.0）中的行为已更改，该行为在§20.3.1.16中表示：
...如果没有时区偏移，则日期时间将被解释为本地时间。
因此，您的同事似乎正在通过旧版本的JavaScript引擎执行代码。根据较新的规范，您的字符串将被解释为本地时间，而根据较旧的规范，则将其字符串解释为UTC。既然您说的都是通过Node.js完成的，那么他们应该只需要升级到新版本的Node.js。
如果您需要更多详细信息，我blogged about this behavior前一段时间。
如果您想适应较旧的环境，请考虑自己或使用库来解析日期字符串。有很多选择。通常，许多人不信任附加到Date对象上的字符串解析器，因为它多年来已经发生了变化，具有某些实现特定的行为，并且仍然会做一些愚蠢的事情，例如假设像{{1 }}应该解释为UTC而不是ISO 8601指定的本地时间。