Java TimeZone.getTimeZone（）.getRawOffset（）依赖于什么？

当我在ideone上运行此代码时：我在标准输出中接收

10800000

，当我在本地运行它时，我可以看到

7200000

生成此输出的代码是：

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

---

getRawOffset

方法以毫秒为单位返回当前日期的原始偏移量值（如果适用，不带DST）。除以3600000得到小时数，您将看到您报告的值在IDEOne中为UTC+3，在您的本地环境中为UTC+2

如果我们查看基础条目，我们会看到以下内容：

# 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

中进行的，并且包含在中

Java随每个JRE版本一起提供TZDB更新（并通过一个单独的带外过程，称为）。我们可以查看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

事实上，我们可以在中看到，2016f首先与8u111一起发货，下一个带内版本是与2016i的8u121一起发货。确认Java 8更新112于2016年10月18日发布

因为喀土穆还没有迁移到UTC+2，所以旧版本的Java根本没有这些信息。IDEOne需要更新其JRE版本或run，以携带更新的信息

您的本地环境可能正在更新Java，它具有2017c或更高的时区数据

---

此外，现代Java不应该再使用

Java.util.TimeZone

，而是应该更喜欢使用。使用这些API，您可能不需要直接处理原始偏移量值。

请参阅。这个想法是，问题是自足的，因为外部联系最终会消失。提供一个解释，并说明你正在尝试做什么，以及你得到了什么结果。一般来说，你也应该展示你的研究成果。你做了什么来解决你的问题呢？

TimeZone

类已经过时很久了，Java 1.0和1.1中只有一个过时的日期和时间类。现在，建议您使用及其类

ZoneId

和

ZoneRules

。