Calendar.getInstancegetTime返回的日期为“ GMT”，而不是默认的TimeZone

如何解决Calendar.getInstancegetTime返回的日期为“ GMT”，而不是默认的TimeZone

问题中的第二个输出是在运行爱尔兰时间（欧洲/都柏林）的JVM上的正确预期行为。2017年9月12日，爱尔兰开始夏令时（DST）。尽管没有明确记录，但Date.toString()（在打印时Date从中隐式调用c.getTime()）在JVM的时区中打印日期和时间，该时间和日期在9月被表示为爱尔兰夏令时的IST。

当您Calendar还使用爱尔兰时间在对象上设置日期时，将保留一天中的小时；就您而言，您将获得Jan 01 2007 12:36:24爱尔兰标准时间。现在想象一下，如果将爱尔兰夏令时和爱尔兰标准时间都渲染为IST会造成混淆。您将无法区分。相反，由于爱尔兰的标准时间与格林尼治标准时间一致，因此Date.toString()当日期不在 一年中的夏令时（不是一月）时，将显示此内容。

我的猜测是您的第一个输出来自运行印度时间的JVM。它也被渲染为IST，并且由于印度不使用夏季时间，所以夏季和冬季都使用相同的缩写。

java.time

在了解对您观察到的行为的解释之前，我发表了有关过时的Java日期和时间类的评论。不过，我仍然认为评论不会遥遥无期。这是代码的现代等效项：

    ZonedDateTime zdt = ZonedDateTime.now(ZoneId.of("Europe/Dublin"));
    System.out.println(zdt);
    zdt = zdt.with(LocalDate.of(2007, Month.JANUARY, 1));
    System.out.println(zdt);

它打印

2017-09-12T11:45:33.921+01:00[Europe/Dublin]
2007-01-01T11:45:33.921Z[Europe/Dublin]

如果要使用JVM的时区设置，请使用ZoneId.systemDefault()代替ZoneId.of("Europe/Dublin")。顾名思义，与相反Date，ZonedDateTime确实包含时区。它更符合旧Calendar类别。如您所见，其toString方法Z以明确的区域/城市 格式打印UTC的偏移量（表示零偏移量）和时区名称。我相信这会减少混乱的余地。如果要以特定格式打印日期，请使用DateTimeFormatter。

附录：代码示例输出

为了完整起见，这是运行不同时区（可能呈现为IST）时代码的输出：

• 欧洲/都柏林（同意您的第二项输出）

  Tue Sep 12 11:19:28 IST 2017
  

  Mon Jan 01 11:19:28 GMT 2007

• 亚洲/特拉维夫

  Tue Sep 12 13:19:28 IDT 2017
  

  Mon Jan 01 13:19:28 IST 2007

• 亚洲/加尔各答（同意您的第一个输出）

  Tue Sep 12 15:49:28 IST 2017
  

  Mon Jan 01 15:49:28 IST 2007

解决方法

Calendar c = Calendar.getInstance();
System.out.println(c.getTime());
c.set(2007,1);
System.out.println(c.getTime());

输出：

IST 2017年9月12日12:36:24

IST 2007年1月1日星期一12:36:24

但是，当我在不同的环境中使用相同的代码时，输​​出更改为以下内容：

输出：

IST 2017年9月12日12:36:24

2007年1月1日星期一格林尼治标准时间12:36:24

仅供参考，我尝试在设置值之前和之后打印日历实例的时区，并且两者都在“ IST”中。

我想知道这个的根本原因。