ZonedDateTime.parse(...) vs ZonedDateTime.of(...)

Question

我看到了ZonedDateTime.parse(...)和之间我不明白的区别ZonedDateTime.of(...)。这是示例：

    private static final DateTimeFormatter DATE_TIME_FORMAT = new DateTimeFormatterBuilder()
            .parseCaseInsensitive()
            .appendPattern("dd-MMM-yyyy HH:mm:ss z")
            .toFormatter();

    @Test
    public void dates() {
        assertEquals(
                ZonedDateTime.of(2001, 10, 1, 17, 7, 15, 0, ZoneId.of("EST", ZoneId.SHORT_IDS)),
                ZonedDateTime.parse("01-OCT-2001 17:07:15 EST", DATE_TIME_FORMAT));
    }

令我惊讶的结果不是通过测试，而是：

java.lang.AssertionError: 
Expected :2001-10-01T17:07:15-05:00
Actual   :2001-10-01T17:07:15-04:00[America/New_York]

请对正在发生的事情有什么提示吗？

编辑：似乎问题是在parse(...)方法中EST获取解析为ZoneRegion，其中ZoneId.SHORT_IDS映射EST到ZoneOffset。如果这种不一致背后有什么原因，我会很感兴趣。

Answer 1

问题很简单。

EST 并不意味着你认为它意味着什么。那是因为没有人真正知道这意味着什么；这是模棱两可的，上下文必须提供您的意思。

它有3个主要含义和层次：

1. 这是一个三个字母的首字母缩写词，很多地方都使用它。澳大利亚有东部标准时间。他们称之为EST. 在世界其他地方，如果要使用首字母缩略词，请使用 AEST。至少这个（可能）不是这里的问题，但请注意，如果您使用澳大利亚语言环境解析该字符串，如果它看到 EST 并决定这意味着“澳大利亚/悉尼”，我不会感到太惊讶。

2. 它是 UTC-5 的固定区域偏移量：“东部标准时间”，如纽约（以及其他地点）在冬季观察到的时区。与 EDT 不同的是，它是 UTC-4 的固定偏移量，称为“东部夏令时”，是纽约的时间，但在夏季。请注意，纽约在 11 月 1 日从 EDT 变为 EST，因此在您提供的时间，就该定义而言，纽约不在 EST 上。

3. 无论年份如何，它都是纽约的时间：一个区域而不是一个偏移量；冬季为 UTC-5，夏季为 UTC-4，根据美国政治规则切换。

我会说定义 #2 是最明智的，但其他两个都足够常见，您不能将它们视为错误。

解析时区字符串涉及语言环境，这意味着当您提供非常模糊的内容时，您不知道它会做什么。

事实证明，在您系统的默认语言环境中，EST最终解析为第三个定义，因此它变成了 ZoneId America/New_York。我想知道您是否指的是 UTC-5（您可能没有；在您提供的时间，地球上几乎没有任何地方遵守 UTC-5！），听起来更合理，您实际上是指第三个定义。

ZoneId.of("EST", ZoneId.SHORT_IDS) 使用第二个定义。

因此，这里有两个不同的概念，即使它们都使用首字母缩略词 EST。

我同意 Arvind 的结论：停止将 TLA 用于这些东西，它们太不清楚了。使用全名，例如America/New_York.

我提供了这个答案来向您解释为什么您在这里看到不相等的对象。