尴尬的Java日期创建行为

时间:2011-05-31 11:01:47

标签: java date timezone

当我尝试创建两个日期时,我刚刚发现了Java的Date类的一个非常奇怪的行为:

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

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

输出分别为:

Fri Aug 27 00:00:00 BST 2010
Mon Nov 21 23:59:59 GMT 2011

有没有人见过这样的东西?两个日期都以相同的方式初始化,但是在打印时,第一个以BST显示,后者以GMT显示?

我试图找到解释,但我没有。有人能帮助我吗?

提前致谢!

3 个答案:

答案 0 :(得分:5)

这是记录在案的行为。

来自Date.toString()

  

将此Date对象转换为以下形式的字符串:

 dow mon dd hh:mm:ss zzz yyyy
  

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

您正在使用使用英国夏令时的区域设置并创建应用日光保存规则的日期。这将是当时对本地用户的预期日期形式。

答案 1 :(得分:1)

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

Fri Aug 27 01:00:00 CEST 2010
Tue Nov 22 00:59:59 CET 2011

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

区别在于CEST is the central european summer time,而CET is the central european time(即不是夏令时)。

您似乎在英国语言环境(en_GB或类似地方)中投放,因此您的输出分别显示British Summer TimeGreenwich Mean Time

您指定的第一个日期属于相应的夏令时,而第二个日期则不属于。因此,Java为每个区域设置/时间组合选择适当的时区。

答案 2 :(得分:1)

在尝试了不同的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

请注意,由于从标准时间到夏令时的转换,将11284245999999L增加到1284246000000L会使我们“回到过去”。 这就是Java时间计算的行为方式 - 自1970年1月1日以来的毫秒数不会改变,但它所代表的时间基于时区。