相关疑难解决方法(0)

有什么理由使用ZoneId.of("UTC")而不是ZoneOffset.UTC？

我们知道两者之间的区别，如ZoneOffset.UTC 和 ZoneId.of("UTC") 之间的区别是什么？。

<tl;博士>版本：

• ZoneOffset.UTCZoneOffset返回ID 为“Z”、偏移量为 0 和默认区域规则的meme 。
• ZoneId.of("UTC")返回ZoneRegionID 为“UTC”并ZoneOffset.UTC包含在内。

</tl;博士>

对于这个问题，我假设使用 UTC 仅仅是为了更容易处理日期和时间，而不是因为某些东西实际上可能位于 UTC 区域或其他一些业务原因将其作为实际的 ZoneRegion。

例如，在处理ZonedDateTime. 我发现的唯一区别是它的打印方式不同。

2021-06-10T15:28:25.000000111Z
2021-06-10T15:28:25.000000111Z[UTC]

我们正在就这个问题来回进行代码审查讨论，所以我想这种冲突并不罕见。

到目前为止，这是我的想法

ZoneOffset.UTC

• 它是一个常量（此外，它的偏移值（0）甚至被缓存）。
• 由于缺少区域信息，它的开销（一点点）较少。
• 在 UTC，与任何其他时区一样，无需考虑夏令时或历史变化。
  因此，偏移量 0 通常足以满足我迄今为止遇到的所有用例（例如在具有特定夏令时状态的某个区域区域之间进行转换）。

ZoneId.of("UTC")

• 一般来说，我认为 ZoneRegions 优于 ZoneOffsets，因为存在一系列附加的特定于位置的数据，例如特定的夏令时或历史上的时移。
• 然而，对于 UTC，ZoneId.of("UTC")只是一个区域环绕ZoneOffset.UTC，到目前为止我找不到任何好处。据我所知，在 UTC 中，除了继承的ZoneOffset.UTC规则之外，不存在与区域相关的数据。
• 每次都需要解析。

所以我的_猜测_是：

除非您出于某些（例如商业）原因确实需要 UTC 时区/地区，否则您应该更喜欢ZoneOffset.UTC. 它在性能足迹方面有一个（较小的）优势，而 UTC ZoneRegion 似乎没有提供任何我能看到或想到的好处。

然而，由于 Java Date …