【问题标题】:Inconsistent behaviour for SimpleDateFormat for timezone Amsterdam阿姆斯特丹时区 SimpleDateFormat 的行为不一致
【发布时间】:2011-10-14 16:34:37
【问题描述】:

昨天我遇到了一个问题,一个人的出生日期在使用 XStream 从 Date 编组到 xml 之后又被更改了,然后再次解组到 Date 。以下代码重现了 XStream 的奇怪行为:

System.setProperty("user.timezone", "Europe/Amsterdam");
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.S z");
String textIn = "1933-09-17 00:00:00.0 CET";
Date date = dateFormat.parse(textIn);
String textOut = dateFormat.format(date);

System.out.println("input : " + textIn);
System.out.println("date  : " + date);
System.out.println("output: " + textOut);

结果:

input : 1933-09-17 00:00:00.0 CET
date  : Sun Sep 17 00:19:32 CEST 1933
output: 1933-09-17 00:19:32.0 CEST

我发现它只发生在 1940 年之前的日期。这在某种程度上是可以解释的:在 1940 年的荷兰,从所谓的“Amsterdamse Tijd” (GMT+00h19m32s) 到欧洲时间 (GMT) 发生了变化+01h00m00s)。我无法解释为什么时区更改为节省时间(从 CET 到 CEST)。

如果我将时区更改为柏林

System.setProperty("user.timezone", "Europe/Berlin");

我得到了我期望的结果:

input : 1933-09-17 00:00:00.0 CET
date  : Sun Sep 17 00:00:00 CET 1933
output: 1933-09-17 00:00:00.0 CET

我的服务器位于阿姆斯特丹。我会将服务器的时区设置为柏林,以解决该问题。

我的问题是:您认为这是 SimpleDateFormat 中的错误吗?或者代码是否无效,因为“1933-09-17 00:00:00.0 CET”是阿姆斯特丹位置的无效日期?

如果这是一个错误,应该以及应该在哪里报告? 如果日期输入本身无效,解析方法不应该抛出错误吗?

【问题讨论】:

  • 呸,约会真是头疼。我很想知道这个问题的答案。

标签: java timezone simpledateformat


【解决方案1】:

看起来德国在 1933 年没有进行 CET 到 CEST 的过渡,而荷兰做了:

【讨论】:

  • 谢谢!此人出生在 AMT 时区,如果夏令时有效,则出生在 NST。然后几年出现了 NET 和 NEST,直到现在我们有了 CET 和 CEST。历史从来都不是简单的。希望未来会是!
猜你喜欢
  • 1970-01-01
  • 2014-06-23
  • 2017-06-10
  • 2022-06-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多