1º 夏令时 Java 和 JS 表现出不同的行为答案

【问题标题】：1º Day of Daylight Saving Time Java and JS showing a different behavior1º 夏令时 Java 和 JS 表现出不同的行为
【发布时间】：2012-10-24 11:26:18
【问题描述】：

假设巴西利亚 GMT -0300：DST 于 2012 年 10 月 21 日 00:00:00，时钟应该提前一小时

Java

new Date(2012 - 1900, 9, 21, 0, 0, 0)
Sun Oct 21 01:00:00 BRST 2012

Chrome/FireFox（控制台）

new Date(2012, 9, 21, 0, 0 ,0)
Sat Oct 20 2012 23:00:00 GMT-0300 (Hora oficial do Brasil)

Java 中的结果是我所期待的，但是 JS 中的结果我无法理解。我找到了这个post bjornd 说的地方

这是绝对正确的行为

但没有解释为什么这种行为是可以的。

我的问题是：

为什么 JS 会返回一小时前的日期？

附：我知道 Date 被标记为“弃用”，但我正在使用 GWT；日期是我唯一的选择。

【问题讨论】：

标签： java javascript dst

【解决方案1】：

据我所知，基本上，那个答案是不正确的。我什至对 Java 版本并不完全满意。

从根本上说，您正在尝试构建一个从未发生过的本地日期/时间。从本地时间转换为 UTC 总是很棘手，因为存在三种可能性：

清晰的映射，在大多数时区，每年只有两个小时以外的所有时区都是这种情况
模糊映射，在向后过渡期间，相同的本地时间段出现两次（例如，本地时间变为上午 12:59、上午 1 点、...上午 1:59、上午 1 点、上午 1:59，凌晨 2 点）
“间隙”映射，本地时间段根本不存在（例如，本地时间变为 12:59am、2am、2:01am）

巴西在午夜将时钟向前移动，因此当地时间实际上是：

October 20th 11:58pm
October 20th 11:59pm
October 21st 01:00am
October 21st 01:01am

您要求的当地时间根本没有发生。看起来 Java 只是假设您想将其向前滚动...而 JavaScript 变得混乱 :( 如果您在 2013 年 2 月 16 日开始时要求午夜，JavaScript 结果会更容易理解（但仍然不正确），因为例如 - 时钟会回到 15 日晚上 11 点。16 日上午 12 点是明确的，因为它只能在 15 日晚上 11 点至晚上 11:59 的“第二个”之后发生。

一个好的日期/时间 API（在我非常有偏见的观点）会迫使你说出你希望在进行转换时如何发生歧义和间隙。

【讨论】：

在我看来，差距只能有一种（非异常抛出）方式来处理它们，即“假装人们忘记调整他们的手表”，这就是 Java 似乎在做的事情案子。但是这里的部分问题是 Date 构造函数没有采用 TimeZone 参数，因此它们在本地时区中运行......这使得解析这些日期变得更加困难，因为实际上本地时区在切换期间发生了变化-超过。如果他们采用时区参数，那么就不会有歧义或差距......只留下闰秒问题;-)
@StephenConnolly：不，仍然会存在歧义/差距问题，假设您仍在表达该时区内的本地日期/时间。时区本身不会改变（例如，我仍然在欧洲/伦敦时区，无论是观察 BST 还是 GMT）。间隙也可以通过多种方式处理 - 它可以返回间隙之前的最后一瞬间、间隙之后的第一瞬间、“假装忘记调整手表”的瞬间，或者抛出异常。（抛出异常绝对是一种选择，IMO。）
我了解您解释的三种可能性，但如果永远不会发生，请回到晚上 11 点，因为没有办法确定是否是 2 月 15 日2013 晚上 11:00:00 到晚上 11:59:59 是否为 DST。这不是问题，因为我们在夏令时结束时没有“差距”。那么，我应该接受 JS 就是错的答案吗？
@Mauro：我将重写关于二月部分的部分；晚上 11 点会模棱两可，但上午 12 点不会。是的，在这种情况下，它真的，真的看起来像一个 JS 错误。
@JonSkeet，不，我是说时区应该始终是构造函数的一部分，因为然后指定“BRT”或“BRST”将消除问题......这些 3/4 字母代码不是唯一的...... IST 也被其他国家/地区使用，而不仅仅是“爱尔兰夏令时”