问题
I have a Java web application running on Tomcat to create scheduled events for a client. I have a question regarding the default date time for underlying operating system, Tomcat and JVM.
When I retrieve the Date through the Java code it is similar to the underlying operating system. Then I changed the operating system time just to simulate the Daylight Saving effect, but the application does not reflect the operating system time.
Then I read more about it and found that the JRE is responsible for maintaining the Date Time for the JVM. However when I reboot the tomcat it starts reflecting the operating system time.
Can any one please explain the theory behind this? As my readings we can use TZupdater to update the latest date time changes for the JRE and the system will handle the Daylight Saving without the restart of the tomcat.
回答1:
There are different settings involved here:
- The system has not only a current time, but also a time zone.
- The JVM in which Tomcat runs also has a time zone setting.
The time zone settings of the operating system and of the JVM are taking care of summer time (daylight saving time, DST) for you. So setting the system time to reflect DST is the incorrect way. Instead you should set the operating system time zone to the desired time zone, and the operating system will automatically adjust the time it displays when DST begins in spring and when it ends in autumn.
You really shouldn’t use Date for representing date and time. That class is long outdated, and the classes of java.time, the modern Java date and time API, are much nicer to work with. If you do anyway, your Date does not contain the time in your time zone. Instead it represents a point on the time line independent of time zones. What confuses many is that when you print the date, thereby implicitly calling its toString method, then that toString method grabs the time zone setting of your JVM and uses it for generating the string. This may give you the false impression that the Date has a time zone in it.
Now I mentioned the JVM time zone setting. Unless something is done to obtain something else, the JVM time zone setting is initialized to the operating time zone setting when the JVM is launched, but is not changed even if you change the operating system setting. On the other hand the JVM setting may be changed from a Java program running in the JVM (this includes any program running in your Tomcat server).
Generally the best way to get the current time in Java is to specify time zone yourself. For example:
System.out.println(ZonedDateTime.now(ZoneId.of("Pacific/Noumea")));
This just printed
2018-03-06T06:20:23.903292+11:00[Pacific/Noumea]
What happened was that Java took the current time from the operating system clock and translated it to the current time in the specified time zone, taking DST into account if DST is in effect at this time of year. Contrary to a Date a ZonedDateTime is date and time and a time zone. ZonedDateTime is one of the classes from java.time, the modern API I mentioned.
By specifying an explicit time zone you are independent of any setting that might have been changed unpredictably. And by relying on your desired time zone you are free from changing the system clock when DST begins and ends.
And yes, you are correct that you may need to use the TZupdater to make sure that your JVM contains the correct information, for example about DST for your time zone. Politicians sometimes change the DST rules on a short notice, and the world’s Java installations don’t change automatically when that happens. When you upgrade your Java version you will typically also get the latest time zone information. But if you are using a less-than-brand-new Java version, TZupdater is the way to make sure your time zone information is current.
Link: All about java.util.Date
来源：https://stackoverflow.com/questions/49113219/handle-daylight-saving-in-tomcat-without-server-restart