Joda时区与JDK的时区不同

Question

在我的客户中，我有以下代码：

System.out.println("Java tz: " + TimeZone.getDefault());
System.out.println("Joda tz: " + ISOChronology.getInstance());

这两条线接连地运行。我从不设置时区或user.timezone手动设置，仅依靠从OS和本地系统读取的默认设置。

执行后，它们产生：

Java tz: sun.util.calendar.ZoneInfo[id="UTC",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
Joda tz: ISOChronology[America/Phoenix]

系统时区确实是Phoenix，而不是UTC。Joda如何正确而JDK如何错误？

编辑 ：这是Windows 7 x64主机，JRE是1.6.22 x64。

编辑2
：不要尝试复制它。它只会在某些系统上失败，而不是在所有系统上失败（例如3k用户群中的几十个）。我已经知道乔达检查user.timezone，然后TimeZone.getDefault()。因此，我正在寻找一种解释，TimeZone直接打电话给我和Joda自己做之间有什么区别。

Answer 1

当您说“从操作系统和本地系统读取默认值”时，没有一个明确定义的地方可以读取此默认值。甚至API文档本身也说

获取TimeZone此主机的默认值。默认值的来源TimeZone可能会因实现方式而异。

因此，简单的答案是Joda和您的JVM从不同的信息源推断默认时区。需要记住的一点是， 默认值是一个guess ，而不是JVM绝对可以访问的值。

对于Linux上的Sun的1.5.0_06 JVM，使用以下顺序：

1. 期待环境变量TZ
2. 查找文件/ etc / sysconfig / clock并尝试找到“ ZONE”条目。
3. 递归比较/ etc / localtime中的内容与/ usr / share / zoneinfo中每个文件的内容。当内容匹配时，它将返回从/ usr / share / zoneinfo引用的路径和文件名。

Joda 1.6.2使用：

1. 系统属性user.timezone。
2. 如果以上null不是有效标识符，TimeZone则使用JDK的默认值。
3. 如果失败，UTC则使用。

因此， 如果
您具有上述版本的JDK和Joda，建议user.timezone您在您的环境中设置该属性。但是，其他版本可能会使用其他算法来获取默认值。

编辑：在Sun的JDK
1.6.0_22中，默认搜索user.timezone也会首先检查该属性，如果找不到该user.country属性，则它将查找该属性以获取某个国家的默认值。如果两者均未设置，GMT则使用默认值。因此，您观察到的结果可能会随JVM版本而改变。

编辑2：如果您同时拥有两个源（实际上两个源均可用），则只需对其进行跟踪即可！逐步执行Joda调用，以查看它是否确实遵从java.util.TimeZone.getDefault()，并查看返回的值是什么。然后直接调用JDK方法，然后看得到什么。

查看JDK源代码，似乎默认时区是通过可继承线程本地访问的。因此，如果有人在某处打电话TimeZone.setDefault()，则可能在其他线程中可见，也可能看不见，这取决于他们是否已经查看了该版本。如果您从调试调用中获得明显的异常结果，则很可能是由于
不同的线程可能具有不同的默认TimeZones造成的 。