java - TimeZone.getTimeZone().getRawOffset() 取决于什么？

Question

当我在 ideone 上运行此代码时: https://ideone.com/sm2SHC我在标准输出中收到 10800000，当我在本地运行它时，我可以看到 7200000。

产生此输出的代码是:

System.out.println(TimeZone.getTimeZone("Africa/Khartoum").getRawOffset());

Answer 1

getRawOffset 方法，as described in the documentation ，返回当前日期的原始偏移值(如果适用，则不含 DST)，以毫秒为单位。除以 3600000 即可得到小时数，您将看到报告的值在 IDEOne 中为 UTC+3，在本地环境中为 UTC+2。

如果我们看看底层 tz database条目for this time zone ，我们看到以下内容:

# Zone  NAME            GMTOFF   RULES  FORMAT  [UNTIL]
Zone    Africa/Khartoum 2:10:08  -      LMT     1931
                        2:00     Sudan  CA%sT   2000 Jan 15 12:00
                        3:00     -      EAT     2017 Nov  1
                        2:00     -      CAT

最后两个条目显示 UTC+3 的有效期直至 2017 年 11 月 1 日，此时喀土穆切换为 UTC+2。深入挖掘，您会发现此更改是在版本 2017c 中进行的，并且包含在 the release announcement here 中。 .

Java 随每个 JRE 版本一起提供 TZDB 更新(并通过名为 TZUpdater 的单独带外进程)。我们可以update your IDEOne查看那里正在运行什么版本的 TZDB 和 JRE。

System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());
System.out.println(System.getProperty("java.version"));

// outputs [2016f] and 1.8.0_112

确实，我们可以在 Oracle's list of time zone versions in JRE 中看到，2016f 首次搭载 8u111，下一个带内版本是 2016i 的 8u121。 The Wikipedia page on Java Updates确认 Java 8 更新 112 于 2016 年 10 月 18 日发布。

由于喀土穆尚未转移到 UTC+2，因此旧版本的 Java 根本没有该信息。 IDEOne 需要更新其 JRE 版本，或运行 TZUpdater ，携带更多当前信息。

您的本地环境可能使用较新的 Java 更新，其中包含 2017c 或更高的时区数据。

此外，现代 Java 不应再使用 java.util.TimeZone，而应该更喜欢 improved java.time APIs反而。使用这些 API，您可能不需要直接使用原始偏移值。