我有一个在 Tomcat 上运行的 Java Web 应用程序来为客户端创建预定事件。我对底层操作系统、Tomcat 和 JVM 的默认日期时间有疑问。
当我通过 Java 代码检索 Date 时，它类似于底层操作系统。然后我更改了操作系统时间只是为了模拟夏令时效果，但是应用程序并没有反映操作系统时间。
然后我阅读了更多关于它的内容，发现 JRE 负责维护 JVM 的日期时间。但是，当我重新启动 tomcat 时，它开始反映操作系统时间。
谁能解释一下这背后的理论？根据我的阅读，我们可以使用 TZupdater 更新 JRE 的最新日期时间更改，系统将处理夏令时，而无需重新启动 tomcat。
【问题讨论】：
这里涉及到不同的设置：
操作系统和 JVM 的时区设置为您处理夏令时（夏令时，DST）。所以设置系统时间来反映夏令时是不正确的方法。相反，您应该将操作系统时区设置为所需的时区，操作系统会自动调整显示的时间，即春季夏令时开始和秋季结束时显示的时间。
你真的不应该使用Date 来表示日期和时间。该类早已过时，而现代 Java 日期和时间 API 的 java.time 类更易于使用。无论如何，您的Date 不包含您所在时区的时间。相反，它表示独立于时区的时间线上的一个点。让很多人感到困惑的是，当您打印日期时，隐式调用其toString 方法，然后toString 方法获取您的JVM 的时区设置并使用它来生成字符串。这可能会让您误以为Date 中包含时区。
现在我提到了 JVM 时区设置。除非为获取其他内容而进行了某些操作，否则 JVM 时区设置会在 JVM 启动时初始化为运行时区设置，但即使您更改操作系统设置也不会更改。另一方面，JVM 设置可能会从在 JVM 中运行的 Java 程序更改（这包括在 Tomcat 服务器中运行的任何程序）。
通常，在 Java 中获取当前时间的最佳方法是自己指定时区。例如：
System.out.println(ZonedDateTime.now(ZoneId.of("Pacific/Noumea")));
这是刚刚打印出来的
2018-03-06T06:20:23.903292+11:00[太平洋/努美阿]
发生的情况是，Java 从操作系统时钟获取当前时间并将其转换为指定时区的当前时间，如果 DST 在一年中的这个时候有效，则将 DST 考虑在内。与Date 相反，ZonedDateTime 是日期和时间和时区。 ZonedDateTime 是我提到的现代 API java.time 中的类之一。
通过指定一个明确的时区，您可以独立于任何可能已被意外更改的设置。通过依赖您想要的时区，您无需在 DST 开始和结束时更改系统时钟。
是的，您是正确的，您可能需要使用 TZupdater 来确保您的 JVM 包含正确的信息，例如您所在时区的 DST。政治家有时会在短时间内更改 DST 规则，而当这种情况发生时，世界上的 Java 安装不会自动更改。当您升级 Java 版本时，您通常还会获得最新的时区信息。但是，如果您使用的不是全新的 Java 版本，TZupdater 是确保您的时区信息是最新的方法。
【讨论】：