尴尬的 Java 日期创建行为答案

【问题标题】：Awkward Java Date creation behaviour尴尬的 Java 日期创建行为
【发布时间】：2011-05-31 11:01:47
【问题描述】：

当我尝试创建两个日期时，我刚刚遇到了 Java 的 Date 类的一个非常奇怪的行为：

Date startDate = new Date(1282863600000L);
System.out.println(startDate);

Date endDate = new Date(1321919999000L);
System.out.println(endDate);

输出分别为：

2010 年 8 月 27 日星期五 00:00:00 BST 2011 年 11 月 21 日星期一 23:59:59 GMT

有人见过这样的吗？两个日期都以相同的方式初始化，但是打印时第一个显示在 BST 中，而后者在 GMT 中显示？

我试图找到对此的解释，但我没有。有人可以帮我吗？

提前致谢！

【问题讨论】：

您还记得由于夏令时而将时钟向前/向后缠绕一个小时吗？ ;)

标签： java date timezone

【解决方案1】：

这是记录在案的行为。

来自Date.toString()：

将此日期对象转换为以下形式的字符串：

 dow mon dd hh:mm:ss zzz yyyy

zzz 是时区（可能反映夏令时）。标准时区缩写包括方法 parse 识别的缩写。如果时区信息不可用，则 zzz 为空 - 也就是说，它根本不包含任何字符。

您正在使用使用英国夏令时的区域设置并创建适用夏令时规则的日期。对于本地用户来说，这将是当时日期的预期形式。

【讨论】：

【解决方案2】：

对我来说，这段代码的输出是

2010 年 8 月 27 日星期五 01:00:00 CEST
2011 年 11 月 22 日星期二 00:59:59 CET

确切的结果取决于 Java 在您的系统上使用的默认语言环境。

区别在于CEST is the central european summer time，而CET is the central european time（即不是夏令时）。

您似乎在英国语言环境中运行（en_GB 或类似语言），因此您的输出分别显示British Summer Time 和Greenwich Mean Time。

您指定的第一个日期属于各自的夏令时，而第二个则不属于。因此 Java 会为每个语言环境/时间组合选择合适的时区。

【讨论】：

【解决方案3】：

在尝试了不同的long 值之后，我得到了这个：

Date startDate1 = new Date(1284245999999L);
Date startDate2 = new Date(1284246000000L);
System.out.println(startDate1);
System.out.println(startDate2);

Date endDate = new Date(1321919999000L);
System.out.println(endDate);

输出是：

Sun Sep 12 01:59:59 IDT 2010
Sun Sep 12 01:00:00 IST 2010 <-- Long value is greater, but due to DST changes, actual time is one hour earlier
Tue Nov 22 01:59:59 IST 2011

请注意，由于从标准时间到夏令时的过渡，将 long 从 1284245999999L 增加到 1284246000000L 增加 1 会使我们“回到过去”。
这就是 Java 时间计算的行为方式——自 1970 年 1 月 1 日以来的毫秒数没有改变，但它表示的时间是基于时区的。

【讨论】：

谢谢大家！确实很有帮助的答案！