In the Access group A platform, found to record an interface to the test environment playback, found that the interface in the same parameter, a start_day a end_day, but the playback of the time will call the database query, it is very strange;
Check the business code, found that there is really logic will lead to a multi-query, so focus on the data changes, and found that the recording playback two times inconsistent, 12 hours difference;
Continue to check the business log, found that the first time the DB, two times the time is different, that is, the interface into the parameter (string type) consistent, through the application of the conversion to the int type, the problem, the difference of 12 hours;
So guess is time zone problem!!!
# Ideas & Solutions
1. Now that it's time zone problem, it's better to go to record machine A and replay machine B to see the time zone through the Linux command
Found all Fri, Jul 2018 12:11:22 +0800
It's all +8, East eight.
Date + "%Z%Z"
It turns out it's the same. CST +0800
2. No, the time zone is the same, then the problem is Java execution is not the same? Checked the JDK version and found a consistent
3. Then execute Java code on both machines to try it out:
// output The current default time zone
Found the problem, two machines print inconsistent, A is Shanghai, and B is New York ...
4. So the question becomes where does the JVM get the time zone? The following query is roughly as follows:
1) If there is an environment variable TZ setting, use the time zone set in TZ
2) Find the value of "ZONE" in the/etc/sysconfig/clock file
3) If not, then use the/etc/localtime and/usr/share/zoneinfo to match the time zone file, if a match is found, return the corresponding path and file name.
In simple terms:
TZ environment variable--/etc/sysconfig/clock file--/etc/localtime file Find
5. So began to set, TZ no matter, add/etc/sysconfig/clock, the following operations:
Create a new/etc/sysconfig/clock with the following content:
Then continue to check the time zone, or not!!
6. Continue setting up the/etc/localtime file as follows:
is to initialize the/etc/localtime and then bind the East eight zone
7. After viewing the time zone succeeded, re-execute Java code, found normal
8. Continue to flip through the data and discover:
The configuration file for the time zone is/etc/sysconfig/clock. You can modify this configuration file with the Tzselect command, and then modify it according to the command prompt.
However, in actual work, it is found that this method is not able to make the time settings on the server to take effect immediately, and using Ntpdate to synchronize the time server can not change the time. Even if you use the date command to set the time manually, if you use Ntpdate to synchronize time, the time will be changed to the original error time zone. The machines that are produced are often very important and cannot be restarted or operated.
1)/etc/sysconfig/clock file, only for Hwclock
The command is valid and only works when the system starts and shuts down (modifies the utc=true to Utc=false before and after it executes Hwclock (--UTC,
or--localtime) has not changed, to restart the system before it takes effect);
When utc=false in/etc/sysconfig/clock, date, hwclock, Hwclcok--localtime output time should be consistent, and at this time Hwclock--utc is meaningless;
When utc=ture in/etc/sysconfig/clock, the output of date and hwclock is consistent, and the output of Hwclock--localtime is UTC time;
When the system shuts down, the system time is synchronized to the hardware clock, and when the system starts, it is updated from the hardware clock read time to the system, all 2 steps to set the time zone conversion based on the parameters of UTC in the/etc/sysconfig/clock file.
This means that modifying the/etc/sysconfi/clock is possible, but it does not take effect immediately and requires a reboot. Then everything's going to be all right.
JVM Linux Time zone settings