操作系统时区更改tomcat需要重启 [英] os timezone change tomcat need restart
问题描述
我的Web应用程序在Apache Tomcat 7.0上运行。我们正在调用java util calendar以获取服务器日期时间。问题是，如果更改了系统时区，则Java日历将以旧时区的日期时间运行。
My web application running on Apache Tomcat 7.0. We are calling java util calendar to get the server date-time. The problem is, if the system timezone is changed, the java calendar keeps running with the date-time of the "old" timezone.
Tomcat使用的JDK是-JDk1 .6
JDK used by Tomcat is - JDk1.6
您能告诉我们为什么tomcat需要重新启动以反映新时区吗？
Could you please tell us why tomcat need restart to reflect new timezone?
推荐答案
tl; dr
尽可能在UTC工作。
tl;dr
Work in UTC whenever possible.
Instant.now() // Capture current moment in UTC.
从不依赖于主机操作系统，JVM或数据库的当前默认时区设置。
Never depend on current default time zone setting of your host OS, your JVM, or your database. Specify desired/expected time zone explicitly.
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, same point on the timeline, different wall-clock time.
从不依赖于服务器的时区设置
真正的问题是，您所拥有的代码取决于您无法控制的方面，并且可以随时更改：JVM的当前默认时区。
Never depend on server’s time zone setting
The real problem is that you have code depending on an aspect over which you have no control and which can be changed at any moment: The JVM’s current default time zone.
您永远不要编写依赖于系统默认时区的代码。而是总是将您的期望/期望时区明确指定为传递给相关类的可选参数。
You should never write code that depends on the system's default time zone. Instead, always specify your desired/expected time zone explicitly as an optional argument passed to relevant classes.
问题是，如果系统时区更改后，Java日历将以旧时区的日期时间运行。
The problem is, if the system timezone is changed, the java calendar keeps running with the date-time of the "old" timezone.
主机操作系统（OS）具有自己的当前默认时区设置和自己的时区定义（ tzdata ）。与您的数据库服务器同上；如果它具有诸如Postgres之类的日期时间处理功能，它可能会在内部存储自己的 tzdata 。而且，您的JVM也具有其自己的当前默认时区设置和其自己的时区定义（ tzdata ）。当定义更改为感兴趣的时区时，您应该通过软件产品版本更新或特定于tzdata的更新程序在所有三个位置更新 tzdata 。
The host operating system (OS) has its own current default time zone setting and its own time zone definition (tzdata). Ditto for your database server; if sophisticated in date-time handling such as Postgres, it may have its own tzdata internally stored. And your JVM too has its own current default time zone setting and its own time zone definition (tzdata). When the definition changes for time zones of interest, you should update the tzdata in all three places, either by a software product version update or by a tzdata-specific updater.
我知道所有JVM启动时的默认实现，都是将其当前的默认时区设置为主机OS的默认时区。 在JVM启动后，更改主机操作系统时区设置应该对您的JVM没有影响，至少在我所看到的Oracle和OpenJDK实现中没有影响。
All JVM implementations I know of default on launch to setting its own current default time zone to that of the host OS. After JVM launch, changing the host OS time zone setting should have no effect on your JVM, at least not in the Oracle and OpenJDK implementations I have seen.
我们正在调用Java util日历来获取服务器日期时间。
We are calling java util calendar to get the server date-time.
请不要使用麻烦的旧版日期时间类，例如 Date & 日历。这些已被 java.time 类完全取代。
Never use the troublesome old legacy date-time classes such as Date & Calendar. These have been entirely supplanted by the java.time classes.
请告诉我们为什么tomcat需要重启反映新的时区？
Could you please tell us why tomcat need restart to reflect new timezone?
我想您的Web应用程序不适当地缓存了UTC偏移量，而不是总是使用时间区。与UTC的偏移量只是距UTC数小时-数分钟-秒的偏移量。时区远不止于此，它是过去，现在和将来对特定区域人们使用的偏移量的历史记录。因此，请始终使用时区，而不仅仅是偏移量。有关更多详细信息，请参见我的答案以了解类似的问题。
I would guess that your web app is inappropriately caching an offset-from-UTC rather than always using a time zone. An offset-from-UTC is just a number of hours-minutes-seconds of displacement from UTC. A time zone is much more, a history of past, present, and future changes to the offset used by the people of a particular region. So always use a time zone rather than a mere offset. See my Answer to a similar Question for much more detail.
以大陆/地区的格式指定适当的时区名称 ，例如 美国/蒙特利尔 ， 非洲/卡萨布兰卡 或 Pacific / Auckland 。请勿使用3-4个字母的缩写，例如 EST 或 IST ，因为它们不是 真实时区，不是标准化的，甚至不是唯一的（！）。
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ;
如果要使用JVM的当前默认时区，请提出要求并作为参数传递。如果省略，则会隐式应用JVM的当前默认值。最好明确一点，因为默认值可以在运行时的任何时候在JVM中任何应用程序的任何线程中的任何代码进行更改。
If you want to use the JVM’s current default time zone, ask for it and pass as an argument. If omitted, the JVM’s current default is applied implicitly. Better to be explicit, as the default may be changed at any moment during runtime by any code in any thread of any app within the JVM.
ZoneId z = ZoneId.systemDefault() ; // Get JVM’s current default time zone.
UTC
通常最好始终使用在UTC中，除非您的业务逻辑或用户界面需要区域。您应该学会在UTC中思考，工作，记录，存储和交换数据。
UTC
Generally best to always work in UTC unless a zone is required by your business logic or by your user-interface. You should learn to think, work, log, store, and exchange data in UTC. Forget about your own parochial time zone while at work as a programmer or admin.
Instant 类表示 UTC ，分辨率为纳秒（最多十进制的九（9）个数字）。
The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Instant instant = Instant.now() ; // Capture current moment in UTC.
关于 java.time
java.time 框架内置于Java 8及更高版本中。这些类取代了麻烦的旧旧版日期时间类，例如 java.util.Date ， Calendar ，& SimpleDateFormat 。
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
Joda-Time 项目，现在处于维护模式 ，建议迁移到 java.time 类。
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
要了解更多信息，请参见 Oracle教程 。并在Stack Overflow中搜索许多示例和说明。规范为 JSR 310 。
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
您可以直接与数据库交换 java.time 对象。使用符合 java.sql。* 类。
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.
在哪里获取java.time类？
Where to obtain the java.time classes?
- Java SE 8 ， Java SE 9 ，然后是
- 内置。
- 具有捆绑实现的标准Java API的一部分。
- Java 9添加了一些次要功能和修复。
- Java SE 8, Java SE 9, and later
- Built-in.
- Part of the standard Java API with a bundled implementation.
- Java 9 adds some minor features and fixes.
- 许多java.time功能都反向移植到Java 6&
- Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
- 较新版本的java.time类的Android捆绑实现。
- 对于较早的Android（< 26）， ThreeTenABP 项目采用了 ThreeTen-Backport （如上所述）。请参阅 如何使用ThreeTenABP… 。
- Later versions of Android bundle implementations of the java.time classes.
- For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
ThreeTen-Extra 项目使用其他类扩展了java.time。该项目为将来可能在java.time中添加内容打下了基础。您可能会在这里找到一些有用的类，例如
时间间隔，YearWeek，YearQuarter和更多。这篇关于操作系统时区更改tomcat需要重启的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
