为什么 Java 支持秒精度的时区偏移？答案

【问题标题】：Why does Java have support for time zone offsets with seconds precision?为什么 Java 支持秒精度的时区偏移？
【发布时间】：2019-04-23 12:05:30
【问题描述】：

On Wikipedia 时区偏移被解释为与标准 UTC 时间的小时和分钟差异。但是，DateTimeFormatter 支持区域偏移模式 XXXXX，它“输出小时和分钟以及可选的秒，并带有冒号，例如 '+01:30:15'。”

+01:30:15 ISO 之类的偏移量是否有效？如果不是，Java 是根据哪个标准定义这样的偏移量的？

【问题讨论】：

可能它的开发不是基于 Wikipedia 和/或 ISO
如果您查看Wikipedia's article on UTC 下的“另请参阅”部分，您会看到一些与 UTC 有秒（甚至小数秒）偏移的时间标准。特别感兴趣的是TAI (International Atomic Time)是UTC所依据的（相差37s）
@ChrisH 差别是目前 37s！
@ChrisH 绝对！直到去年，我一直在电信行业工作，那里也很重要。
@ChrisH：除了广播，传统的模拟同步机制（字时钟、黑脉冲、三级同步）正在被基于网络的同步所取代，即时基为 TAI 的 PTP。 Broadcast 只是 PTP 的最新用户，它已经在电信、机器人技术和工厂自动化领域建立起来。此外，GPS 时间基于 TAI，固定偏移为 19 秒，因此目前与 UTC 相差 18 秒。

标签： java java-time

【解决方案1】：

ISO-8601 不支持它，但它是在 IANA 时区数据库中记录的有效偏移量。

在 19 世纪末和 20 世纪初的数据中，时区未得到适当标准化的数据中很常见。例如，Europe/Paris 在 1911 年之前的偏移量为 +00:09:21（根据 IANA 数据库）。

我能找到的最新事件是 Africa/Monrovia，它在 1972 年之前有不到一分钟的偏移量！

【讨论】：

GPS 时间也偏离 UTC 秒数（当前为 UTC+00:00:18）。
@Kundor：TAI（例如，用作 PTP 的时基）目前与 UTC 偏移 37 秒，与 GPS 的固定偏移为 19 秒。
@EricLippert：确实感觉它几乎是为我写的，是的 :) （而且我发现我曾经发现最近出现的控制台应用程序的长度不到 25 行，这让我很高兴。可以可能用 LINQ 写得更简短，但可能不太可读......）
@EricLippert：原来 LINQ 版本更具可读性：gist.github.com/jskeet/f1c236d305ad5cb89daafd87941b4d88
@JonSkeet：您的 cmets 启发了我想出如何在 GNU 系统上执行此操作；我想出了这个 shell 单线：find /usr/share/zoneinfo -type f -exec zdump -i '{}' + | awk '/^TZ/ {curtz=$1} /[+-][0-9]{6}/ {getline; print $1, curtz}' | sort。可读性的判断留给旁观者......

【解决方案2】：

额外精确的一个原因是我们都熟悉的国家时区并不是故事的结局。

如果您查看Wikipedia's article on UTC 下的“另请参阅”部分，您会看到与 UTC 有秒（甚至小数秒）偏移的时间标准选择。特别感兴趣的是TAI (International Atomic Time)，其中以UTC为基础。目前相差 37 秒，因为 UTC 包括闰秒，而 TAI 不包括。因此，支持父标准需要二级精度。

GPS time 也从 UTC 偏移数秒（相对于 TAI 的偏移固定为 19 秒）。 GPS 时间和 TAI（或其其他衍生物）对于导航、电信/广播和空间科学非常重要。

一旦你进入天文学，事情就会变得更加复杂。 Terrestrial time（维基百科）与更常见的比例有小数偏移：TT ≅ TAI + 32.184 s（精确到毫秒；TT 比这复杂得多）。

进一步阅读，因为它尚未与此问题相关联：Falsehoods programmers believe about time (and timezones, dates, etc.) - 包括一些有趣的背景。

【讨论】：

问题下的 cmets 已经增长到足以让我认为答案是值得的
好的，所以存在秒偏移量，但表示它们是否常见，例如作为2017-03-28T23:40:06.000+01:30:15?这使得它们不是 ISO 有效的。
@MichalKordas 不必在编写代码的层面上处理它们，我不知道。可以说完全支持这些时间标准意味着超越 ISO 有效性。
ISO 禁止这种格式还是它不符合 ISO-8601？（也有一些版本）（对不起，太忙了，无法检查整个 ISO [:-)）（（并且 ISO 是许多标准之一））
@CarlosHeuberger 我无权访问全文。从我看到的所有摘要中，它不包括在内。如果没有明确提及，这是否意味着它被禁止？允许吗？超出范围？