有什么理由使用zoneid.of（“utc”）而不是zoneoffset.utc？

Question

版本：

• zoneoffset.utc返回一个zoneoffset，其ID为“z”，偏移量为0，默认区域规则。
• zoneid.of（“utc”）返回一个zoneRegion，包含ID“utc”和zoneoffset.utc。

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

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

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

• 它是一个常量（此外，它的偏移量值（0）甚至被缓存）。
• 由于缺少区域信息，它的开销少了一点。
• 在UTC时，不需要考虑夏时制时间或历史变化，就像在任何其他时区一样。
  因此，对于我迄今为止遇到的所有用例来说，偏移量为0就足够了（比如转换到具有特定夏时制状态的某个区域）。

• 总的来说，我认为ZoneRegions比ZoneOffsets更受欢迎，因为有一系列额外的特定位置的数据，如特定的夏时制或历史上的时间移位。
• 但是，对于UTC，zoneid.of（“UTC”）只是围绕zoneoffset.UTC的一个区域，到目前为止我还没有发现任何好处。据我所知，在UTC中，除了继承的zoneoffset.UTC规则之外，不存在与区域相关的数据。
• 每次都需要解析。

除非出于某些原因（例如业务）确实需要UTC时区/地区，否则您应该首选ZoneOffset.UTC。它有一个（次要）的进步在它的性能足迹和UTC ZoneRegion似乎没有提供任何好处，我可以看到或想到。

但是，由于Java Date Time API的复杂性，很难判断我在本文的讨论中是否遗漏了什么。
有人应该使用zoneid.of（“UTC”）吗？

Answer 1

有人应该使用zoneid.of（“UTC”）有什么理由吗？

我（现在）想不出任何好的理由。

然而，这样做并不是特别糟糕。在进行查找时很可能会有很小的运行时成本，但这不太可能重要。并且这两种形式(IMO)具有同等的可读性。

   String zoneName = "UTC";  // my default
   // Try to get a non-default zone
   // ...
   id = ZoneId.of(zoneName);

   String zoneName = null;
   // Try to get a non-default zone
   // ...
   id = zoneName == null ? ZoneId.UTC : ZoneId.of(zoneName);