Shulou(Shulou.com)06/02 Report--

This article mainly introduces the JDK time zone TimeZone and operating system inconsistent how to do, the article is very detailed, has a certain reference value, interested friends must read it!

[background] the migration of a Windows server involves operating systems, applications and databases, where:

1. The operating system is run by Windows Server 2003 Murray-> Windows Server 2008

two。 Database: Oracle 10.2.0.4 Oracle-> Oracle 11.2.0.3

3. The scope of discussion of application migration in this blog post

The previous plan has been reviewed for several rounds, and the improvement has been modified many times. The test environment has also been tested many times. He thought that everything would be smooth, foolproof and full of confidence in the change of the production environment, but he was soon slapped by reality. After combing, there are two main problems encountered. The following plan is divided into two parts to be summarized. If there are any mistakes, please correct them.

After the server migration was completed, there was an exception in the startup timing job, which was supposed to generate a T-1 file. Somehow the file became T-2. When something goes wrong, the developer is not on the spot, based on the principle of not bothering others first. The first reaction is that it may be caused by database migration.

To troubleshoot the database, we queried the common time variables sysdate,systimestamp,localtimestamp and current_timestamp and found that the output was the same as the natural time.

SELECT sysdate FROM dual

SYSDATE

-

20170409 07:56:19

SELECT systimestamp FROM dual

SYSTIMESTAMP

09-APR-17 07.56.52.311941 AM + 08:00

SELECT localtimestamp FROM dual

LOCALTIMESTAMP

09-APR-17 07.59.04.507493 AM

SELECT current_timestamp FROM dual

CURRENT_TIMESTAMP

09-APR-17 07.59.17.414758 AM + 08:00

So it has nothing to do with the database? While hesitating, when I started the scheduled job again, I found that the execution result was correct, the T1 file was generated, and the contents of the file were not abnormal. Strange, but the timing work finally executed normally, because there are other things to be busy, this matter has not been analyzed in depth.

Sadly, the problem reappeared the next day, and the situation was almost the same as the day before: the job was abnormal at the beginning, analyzed for a period of time, and it was normal to restart the job again. What happened? It seems that this is not an accidental phenomenon, it is necessary to study it carefully and thoroughly. In the process of analysis, we found a very interesting phenomenon: if the job is executed before 8: 00, it will be abnormal, and the job will execute normally after 8: 00. Is it caused by the time zone? No, the previous query has been confirmed, the database time zone and time are fine. To further confirm that the database time zone is normal, take a look at the dbtimezone variable.

Click (here) to collapse or open

SELECT dbtimezone FROM dual

DBTIME

-

+ 08:00

Basically checked the causes of the database, as a DBA I can not help but breathe a sigh of relief. The following analysis can be relaxed, there is no need to worry, . Since it is suspected that the time zone is caused, let's see if it is the time zone problem of the operating system. However, it is a pity that it is confirmed that the operating system time zone setting is also correct: East 8. After some confirmation and investigation, no problem has been found in the parameter setting of the server and database, so find the developer to ask for the code. The code is very simple, and the useful contents of the interception are as follows:

Click (here) to collapse or open

String strCreDate = new java.sql.Date (new java.util.Date (). GetTime ()-86400000) .toString ()

The specific generation of T-1 or T-2 files is determined by the strCreDate variable. Then there seems to be something wrong with the value of the variable strCreDate. We did a set of experiments: before 8 o'clock, the value of strCreDate was Tmuri 2, but after 8 o'clock it became Tmuri 1. 5. To see the JDK time zone clearly, a very simple HelloWorld code is written as follows:

Click (here) to collapse or open

Import java.util.TimeZone

Import java.sql.Date

Public class HelloWorld {

Public static void main (String [] args) {

System.out.print ("current default time zone is")

System.out.println (TimeZone.getDefault ()); / / output the current default time zone

Final TimeZone zone = TimeZone.getTimeZone ("GMT+8"); / / obtain China time zone

TimeZone.setDefault (zone); / / set the time zone

System.out.println (TimeZone.getDefault ()); / / output verification

}

}

The first output is:

The second output is:

Did you find anything? Although the time zone of the operating system is East 8, the time zone acquired by jdk is not East 8, but lack of UTC, which results in a difference of 8 hours, that is, the operation is abnormal before 8: 00 and normal after 8: 00. The problem has been found, that is, the problem of jdk, and the solution is readily solved. The specific measures are as follows:

Find GMT file backup in the following four directories (Java\ jre6\ lib\ zi\ Etc, Java\ jre6\ lib\ zi, Java\ jdk1.6.0_18\ jre\ lib\ zi\ Etc, Java\ jdk1.6.0_18\ jre\ lib\ zi), then copy a copy of GMT-8 and rename it to GMT. After the copy is complete, run the java program again to solve the problem!

After following the above method, run the HelloWorld command again, and the output is normal. The observation work was normal the next day. So far, the problem has been dealt with.

These are all the contents of the article "what if the JDK time zone TimeZone is inconsistent with the operating system". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.