Question

在解析问题时，我对DateTimeFormatter withZone方法的行为感到困惑。根据它的文件：

解析时，需要考虑两种不同的情况。如果区域已直接从文本中解析，可能是因为使用了DateTimeFormatterBuilder.appendZoneId（），则此覆盖区域无效。如果没有解析区域，则此覆盖区域将包含在解析结果中，可用于构建时刻和日期时间。

基于此以及DateTimeFormatter.ISO_DATE_TIME解析时区的事实，我希望通过以下两个测试。

@Test
public void testNoZoneInInput() {
    final ZonedDateTime expected = ZonedDateTime.of(2017, 2, 2, 9, 0, 0, 0, ZoneId.of("UTC"));
    final ZonedDateTime actual = ZonedDateTime.parse("2017-02-02T10:00:00", DateTimeFormatter.ISO_DATE_TIME.withZone(ZoneId.of("UTC+1")));
    Assert.assertTrue("Expected " + expected + ", got " + actual + " instead.", expected.isEqual(actual));
}

@Test
public void testWithZoneInInput() {
    final ZonedDateTime expected = ZonedDateTime.of(2017, 2, 2, 9, 0, 0, 0, ZoneId.of("UTC"));
    final ZonedDateTime actual = ZonedDateTime.parse("2017-02-02T09:00:00Z", DateTimeFormatter.ISO_DATE_TIME.withZone(ZoneId.of("UTC+1")));
    Assert.assertTrue("Expected " + expected + ", got " + actual + " instead.", expected.isEqual(actual));
}

但前者确实如此，后者并没有：

java.lang.AssertionError：预计2017-02-02T09：00Z [UTC]，取而代之的是2017-02-02T09：00 + 01：00 [UTC + 01:00]。

因此，无论是否在输入中找到时区，似乎都使用覆盖区域。我在this answer中发现了类似的行为，当它提示它可能是JDK中的一个错误时，但我还没有在OpenJDK上找到相应的票据＆＃39;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;的bug追踪器。它实际上是一个错误，还是我对这个文档的理解不正确？

更新我已经用java版本1.8.0_121测试了这个。

Answer 1

这确实是一个错误，只有JDK-8033662，而不是JDK-8177021。据报道，所有Java 8版本的断言都会失败（我确认它失败了1.8.0_172，最近的一台ATM），但是通过了Java 9.

DateTimeFormatter在解析时如何覆盖区域？

1 个答案: