当您说“从操作系统和本地系统读取默认值”时，没有一个明确定义的地方可以读取此默认值。甚至API文档本身也说
获取
TimeZone此主机的默认值。默认值的来源TimeZone可能会因实现方式而异。
因此，简单的答案是Joda和您的JVM从不同的信息源推断默认时区。需要记住的一点是， 默认值是一个guess ，而不是JVM绝对可以访问的值。
对于Linux上的Sun的1.5.0_06 JVM，使用以下顺序：
- 期待环境变量TZ
- 查找文件/ etc / sysconfig / clock并尝试找到“ ZONE”条目。
- 递归比较/ etc / localtime中的内容与/ usr / share / zoneinfo中每个文件的内容。当内容匹配时，它将返回从/ usr / share / zoneinfo引用的路径和文件名。
Joda 1.6.2使用：
- 系统属性
user.timezone
。 - 如果以上
null
不是有效标识符，TimeZone
则使用JDK的默认值。 - 如果失败，
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造成的 。
