TimeZone.getTimeZone().getRawOffset() 取决于什么？答案

【问题标题】：What does TimeZone.getTimeZone().getRawOffset() depends on?TimeZone.getTimeZone().getRawOffset() 取决于什么？
【发布时间】：2018-06-13 15:53:03
【问题描述】：

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

产生这个输出的代码是：

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

【问题讨论】：

请参阅How to Ask。这个想法是问题是独立的，因为外部链接最终会失效。提供minimal reproducible example 以及您要尝试做什么以及获得什么结果的说明。一般来说，您还应该展示您的研究。你做了什么来解决你的问题？
TimeZone 类早已过时，只是 Java 1.0 和 1.1 中过时的日期和时间类之一。今天建议您改用java.time, the modern Java date and time API 及其类ZoneId 和ZoneRules。

标签： java timezone timezone-offset

【解决方案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，您可能不需要直接使用原始偏移值。

【讨论】：