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

Posted 2023-02-24

【中文标题】有啥理由使用 ZoneId.of("UTC") 而不是 ZoneOffset.UTC？

【英文标题】：Is there any reason to use ZoneId.of("UTC") instead of ZoneOffset.UTC?有什么理由使用 ZoneId.of("UTC") 而不是 ZoneOffset.UTC？

【发布时间】：2021-12-26 12:31:59

【问题描述】：

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

我们知道What is the difference between ZoneOffset.UTC and ZoneId.of("UTC")? 中提供的两者之间的区别。

版本：

ZoneOffset.UTC 仅返回一个 ZoneOffset，ID 为“Z”，偏移量为 0，默认区域规则。 ZoneId.of("UTC") 返回一个 ZoneRegion，其 ID 为“UTC”，并包含 ZoneOffset.UTC。

;博士>

对于这个问题，我假设使用 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 规则之外，不存在与地区相关的数据。 每次都需要解析。

---

所以我的 _guess_ 是：

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

但是，由于 Java 日期时间 API 的复杂性，很难判断我是否在本次讨论中遗漏了什么。是否有任何理由应该使用 ZoneId.of("UTC")？强>

【问题讨论】：

我同意你的猜测。

【参考方案1】：

有人应该使用 ZoneId.of("UTC") 吗？

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

但是，这样做并不是非常糟糕。进行查找的运行时成本很可能会很小，但这不太重要。这两种形式（IMO）同样具有可读性。

---

但是，如果区域名称是参数，您可以找到如下代码：

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

哪个（IMO）会比这更好：

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