为什么Java从系统中读取其默认设置

Question

Java正在从安装它的系统中读取区域设置,时区和编码信息(可能还有更多信息).

这往往带来不好的惊喜(昨天就给我带来了一个).假设您的开发和生产服务器设置为TimeZone GMT + 2.然后在生产服务器上部署设置为GMT.2小时的班次可能不容易立即观察.虽然您可以将TimeZone日历传递给日历,但API可能会使用默认时区实例化日历(或日期).

现在,我知道应该小心这些设置,但很容易错过,因此使程序更容易出错.

那么,为什么不是Java有它自己的默认值 - UTF-8,GMT,EN_US(是的,我对非en_US区域,而拥有它默认是罚款).如果需要,应用程序可以通过某些API读取系统设置.

因此,计划将更具可预测性.

那么,这个决定背后的原因是什么？

Answer 1

这不是Java独有的.许多系统默认为系统时区.毕竟,他们还能做些什么呢？

时区是一个棘手的问题,特别是当应用程序需要处理多个时区时.这就是为什么像这样的网站将所有内容都放在UTC中.

至于你的情况,很难评论,因为描述相当模糊,但听起来这是你的错误.如果您在GMT + 2的某个地方保存一个日期(没有时区),然后在GMT加载另一个,那么您做错了.

@Bozho:如果Java自己的默认值是你碰巧想要的,那就不会发生.它改变了问题 - 它实际上并没有解决它. (2认同)
@Bozho Jon提出了一个好点:如果Java有自己的默认值,它会产生同样的问题,但不那么直观.有人不希望在纽约运行应用程序并将其默认为GMT时间. (2认同)

Answer 2

我不明白为什么有一组额外的默认值会使这更容易.当然,这些默认值仍然必须从某个地方读取 - 因此它们可能默认来自操作系统.

如果要影响默认值,通常可以在启动应用程序时设置系统属性,例如:

java -Duser.timezone=Europe/London

等等

就个人而言,我认为问题不在于默认选择 - 事实上它很容易使用.即使是Joda Time(我喜欢很多很多方面)也很容易意外地使用默认时区.编码等也是如此.

编辑:另一种选择是使用调用的main方法(或其他早期初始化模块)

TimeZone.setDefault(TimeZone.getTimeZone("Etc/UTC"));

同样适用于其他系统特定的默认值.