How to accurately express the business logic of Java. util. Date

This work is licensed using the "knowledge sharing signature"-"non-commercial use"-2.5 mainland China License Agreement in the same way.

 

 

The most common Date and Time Operation classes in Java are as follows:

Java. util. Date
Java. SQL. Date
Java. SQL. Time
Java. SQL. Timestamp

 

To accurately express the business logic, avoid using the parent class (Java. util. date. The unique valueof () static method and tostring () method in the three subclasses under the java. SQL package can accurately express the business logic.

System Time and local time

In China, if you call the following code, we will get the result of "08:00:00 ".

// Example 1 <br/> JAVA. util. date obj1 = new Java. util. date (0l); <br/> dateformat = <br/> New simpledateformat ("yyyy-mm-dd hh: mm: SS"); <br/> system. out. println (dateformat. format (obj1); <br/> // print the result: 08:00:00

 

After reading the jdk api, you may have such a question: why is the time obtained by new java. util. Date (0l) Not "00:00:00" but "08:00:00? Why is it difficult to write jdk api errors?
The jdk api is correct. The key is to create Java. util. the number of milliseconds used by the date object is the computer system time, which refers to the number of milliseconds since January 1, 1970 00:00:00 GMT, that is, 00:00:00 GMT. However, when the computer shows us the time as a string, this time has become a local time, for example, using the GMT + 8 time zone in China, so we can see the result of "08:00:00!
After modifying the above code, we can get a clearer concept. For example:

// Example 2 <br/> JAVA. util. date obj1 = new Java. util. date (0l); <br/> dateformat = <br/> New simpledateformat ("yyyy-mm-dd hh: mm: SS 'gmt' Z "); <br/> system. out. println (dateformat. format (obj1); <br/> // print the result: 08:00:00 GMT + 0800

 

The above code shows the result of "08:00:00 GMT + 0800", which proves that our time zone is GMT + 8. When we change the time zone, different results will be displayed for the same system time. For example:

// Example 3 <br/> JAVA. util. date obj1 = new Java. util. date (0l); <br/> timezone. setdefault (timezone. gettimezone ("GMT + 0: 00"); <br/> dateformat = <br/> New simpledateformat ("yyyy-mm-dd hh: mm: SS 'gmt' Z "); <br/> system. out. println (dateformat. format (obj1); <br/> // print the result: 00:00:00 GMT + 0000

 

The above code shows the result of "00:00:00 GMT + 0000", which proves that the current time zone is GMT + 0.

In short, through the above descriptions, we can draw the following conclusions:

1. The system time of all computers is conceptually unified;
2. The same system time will generate different local time according to different time zones;
3. When the time zone is GMT + 0, the system time is the same as the local time.

Precise business logic

In Java, java. util. date is the parent class of the other three classes. Because of this inheritance relationship, all four classes can generate objects through the system time. For example:

Java. util. Date OBJ = new java. SQL. Date (0l );

In this case, when the system time is used as the day when data is generated, the object may have problems in the business logic. For example, run the following code in the GMT + 0 environment:

// Example 4 <br/> // set the time zone to GMT + 0 <br/> timezone. setdefault (timezone. gettimezone ("GMT + 0: 00"); </P> <p> // use the traditional constructor to generate a daily object <br/> JAVA. util. date obj1 = new Java. SQL. date (0l); <br/> JAVA. util. date obj2 = new Java. SQL. date (3600000l); </P> <p> // the business logic is the same <br/> system. out. println (obj1.tostring (); // "1970-01-01" <br/> system. out. println (obj2.tostring (); // "1970-01-01" </P> <p> // syntax comparison is different <br/> system. out. println (obj1.equals (obj2); // false <br/> system. out. println (obj1.compareto (obj2); //-1

 

The two objects generated by the code above represent the GMT Standard Time in the business logic (00:00:00), but the time difference between the two is 1 hour in syntax. The root cause of this phenomenon is that an inaccurate system time is used to reflect the business logic of the daily object.

The business logic of the daily object is the daily information based on the local time.For example, the exact system time describing Greenwich mean time (GMT + 0) 00:00:00 is 0l millisecond; the exact system time describing Beijing time (GMT + 8) 00:00:00 is-28800000l millisecond.

Except java. util. date, the other three classes have their own business scope, for example:
Valid Components of Java. SQL. date include year, month, and day
Valid java. SQL. Time ingredients include hour, minute, and second
Valid java. SQL. timestamp ingredients include year, month, day, hour, minute, second, And nanosecond (in milliseconds)
Because the four types of daily objects use the system time in milliseconds as the standard data, different system time periods may be used to express the same business logic. So how can we convert an inaccurate system time into a precise system time that can accurately express the business logic?

 

1. Use tostring () to obtain the business logic of the daily object
In. util. in the three child classes of date, the traditional constructor and gettime () and settime () methods both use system time to implement them, and they are doomed to inaccurate business logic. If you have used an inaccurate system time to create a daily object in the Java. SQL package, tostring () is the only method that can obtain the exact business logic. The code in Example 4 illustrates this.

 

2. Use valueof () to construct a precise daily object
In order to use accurate system time to accurately express the business logic of a daily object. util. except date, the other three classes provide the second method for generating objects, that is, the valueof () static method. For example:

Java. util. Date obj1 = java. SQL. Date. valueof ("2000-01-01 ");

By passing a string that accurately expresses the daily information, valueof () will generate a daily object composed of precise system time that can reflect accurate business logic. Likewise, such precise daily objects can be compared and judged in syntax, for example:

// Example 5 <br/> // use valueof () to generate a daily object <br/> JAVA. util. date obj1 = Java. SQL. date. valueof ("2000-01-01"); <br/> // use a precise system time to generate a daily object <br/> JAVA. util. date obj2 = new Java. SQL. date (obj1.gettime (); </P> <p> // the business logic is accurate. <br/> system. out. println (obj1.tostring (); // "2000-01-01" <br/> system. out. println (obj2.tostring (); // "2000-01-01" </P> <p> // The syntax is accurate. <br/> system. out. println (obj1.equals (obj2); // true <br/> system. out. println (obj1.compareto (obj2); // 0

 

By understanding valueof () and tostring (), we naturally think of a conversion method that can convert inaccurate system time into precise system time that can accurately express the business logic. Tool class:

Public class datetimeutils {<br/>/** <br/> * obtain a daily object that accurately expresses the business logic <br/> * @ Param OBJ <br/> * inaccurate daily object <br/> * @ return precise daily object <br/> */<br/> Public static Java. SQL. date getlocaldate (Java. util. date OBJ) {<br/> If (OBJ = NULL) <br/> return NULL; </P> <p> JAVA. SQL. date TMP = NULL; <br/> If (Java. SQL. date. class. equals (obj. getclass () {<br/> // if the object type on the original day is Java. SQL. date <br/> // the conversion process is divided into two steps: <br/> // The first step is to obtain Java. SQL. exact business logic value of the date object <br/> string tmpstring = obj. tostring (); <br/> // Step 2: generate a daily object that accurately reflects the business logic <br/> TMP = Java. SQL. date. valueof (tmpstring); <br/>} else {<br/> // if the object type on the original day is not Java. SQL. date <br/> // the conversion process is divided into three steps: <br/> // The first step is to generate a Java program that cannot accurately express the business logic. SQL. date object <br/> OBJ = new Java. SQL. date (obj. gettime (); <br/> // Step 2 and Step 3 and process Java. SQL. the object is the same when the date type is original. <br/> // step 2, get the java. SQL. exact business logic value of the date object <br/> string tmpstring = obj. tostring (); <br/> // Step 3: generate a daily object that accurately reflects the business logic. <br/> TMP = Java. SQL. date. valueof (tmpstring); <br/>}< br/> return TMP; <br/>}< br/>}

 

The preceding method can be simplified:

Public static Java. SQL. date getlocaldate (Java. util. date OBJ) {<br/> If (OBJ = NULL) <br/> return NULL; </P> <p> JAVA. SQL. date TMP = NULL; <br/> If (Java. SQL. date. class. equals (obj. getclass () {<br/> TMP = Java. SQL. date. valueof (obj. tostring (); <br/>}else {<br/> TMP = getlocaldate (New Java. SQL. date (obj. gettime (); <br/>}< br/> return TMP; <br/>}

 

Based on the same principle, you can also obtain the method for converting objects in Java. SQL. Time and Java. SQL. timestamp. The final version is as follows:

Public class datetimeutils {<br/>/** <br/> * obtain a date object that accurately expresses the business logic <br> <br/> * If the original the object type is Java. SQL. date <br> <br/> * the conversion process is divided into two steps: <br> <br/> * Step 1: Obtain Java. SQL. exact business logic value of the date object <br> <br/> * Step 2, generate a daily object that accurately reflects the business logic <br> <br/> * if the object type of the original date is not Java. SQL. date <br> <br/> * the conversion process is divided into three steps: <br> <br/> * Step 1: generate a Java program that cannot accurately express the business logic. SQL. date object <br> <br/> * Step 2 and Step 3: Process Java. SQL. date type original date objects are the same <br/> * @ Param OBJ <br/> * inaccurate date objects <br/> * @ return exact daily object <br/> */<br/> Public static Java. SQL. date getlocaldate (Java. util. date OBJ) {<br/> If (OBJ = NULL) <br/> return NULL; </P> <p> JAVA. SQL. date TMP = NULL; <br/> If (Java. SQL. date. class. equals (obj. getclass () {<br/> TMP = Java. SQL. date. valueof (obj. tostring (); <br/>}else {<br/> TMP = getlocaldate (New Java. SQL. date (obj. gettime (); <br/>}< br/> return TMP; <br/>}</P> <p> Public static Java. SQL. time getlocaltime (Java. util. date OBJ) {<br/> If (OBJ = NULL) <br/> return NULL; </P> <p> JAVA. SQL. time TMP = NULL; <br/> If (Java. SQL. time. class. equals (obj. getclass () {<br/> TMP = Java. SQL. time. valueof (obj. tostring (); <br/>}else {<br/> TMP = getlocaltime (New Java. SQL. time (obj. gettime (); <br/>}< br/> return TMP; <br/>}</P> <p> Public static Java. SQL. timestamp getlocaltimestamp (Java. util. date OBJ) {<br/> If (OBJ = NULL) <br/> return NULL; </P> <p> JAVA. SQL. timestamp TMP = NULL; <br/> If (Java. SQL. timestamp. class. equals (obj. getclass () {<br/> TMP = Java. SQL. timestamp. valueof (obj. tostring (); <br/>}else {<br/> TMP = getlocaltimestamp (New Java. SQL. timestamp (obj. gettime (); <br/>}< br/> return TMP; <br/>}< br/>}

 

We can use this method as follows:
Timezone. setdefault (timezone. gettimezone ("GMT +"); <br/> // The Daily object generated using three methods <br/> JAVA. util. date obj1 = Java. SQL. date. valueof ("1970-01-01"); <br/> JAVA. util. date obj2 = new Java. util. date (0l); <br/> JAVA. util. date obj3 = new Java. SQL. date (0l); </P> <p> // convert in the same way <br/> obj1 = datetimeutils. getlocaldate (obj1); <br/> obj2 = datetimeutils. getlocaldate (obj2); <br/> obj3 = datetimeutils. getlocaldate (obj3); </P> <p> // get the same precise business logic <br/> system. out. println (obj1.gettime (); //-28800000 <br/> system. out. println (obj2.gettime (); //-28800000 <br/> system. out. println (obj3.gettime (); //-28800000 </P> <p> // the business logic is the same <br/> system. out. println (obj1.tostring (); // 1970-01-01 <br/> system. out. println (obj2.tostring (); // 1970-01-01 </P> <p> // The syntax is accurate. <br/> system. out. println (obj1.equals (obj2); // true <br/> system. out. println (obj1.compareto (obj2); // 0

 

It can also be converted between different types of daily objects, such:

Timezone. setdefault (timezone. gettimezone ("GMT + 8:00"); <br/> JAVA. util. date obj1 = <br/> JAVA. SQL. timestamp. valueof ("01:00:00"); </P> <p> // set Java. SQL. timestamp is converted to Java. SQL. time <br/> // The date information is changed to <br/> // The time information is retained <br/> JAVA. util. date obj2 = datetimeutils. getlocaltime (obj1); <br/> system. out. println (obj2.tostring (); // 01:00:00 <br/> system. out. println (obj2.gettime (); //-25200000 </P> <p> // set Java. SQL. time is converted to Java. SQL. date <br/> // retain date information <br/> // change the time information to 00:00:00 <br/> JAVA. util. date obj3 = datetimeutils. getlocaldate (obj2); <br/> system. out. println (obj3.tostring (); // 1970-01-01 <br/> system. out. println (obj3.gettime (); //-28800000