The first appearance of the clouds

“Alley 1983, Chapter 7 of a sunny December night, the typewriter goes on to the next line, close to the truth.”

Ear heard beautiful music, eyes slightly narrowed, Ben holmes is immersed in the music depicts the scenario, the sudden ear rings a bell ding ding bell ringing noise, turned out to be the telephone rang, Ben holmes immediately return to absolute being, “appears to be the case the door”, Ben holmes thought, and then pick up the phone, the end of the phone, eager voice:

‘Hello, is that Inspector Ben Holmes? We’ve got a strange case going on here, and we need you to look into it.”

Hanging up the phone, Ben Holmes hurried to the scene. Arrived at the scene, contact holmes brother immediately report the situation, “the inspector, we here there was a strange case, is that we have two application, use the same database, check the same table in the same field, but the two application interface returned result is very different, one of the interface returns the correct time stamp, The other interface returned an incorrect timestamp, and the time difference between the two timestamps was 14 hours.

Ben Holmes stroked his hand. “Oh? So weird? I’ll take a look at it, “and Holmes begins to reconstruct the scene. First we looked at the database:



Then see the correct return:



Conversion time is:



Conforms to the database, and again looks at the error return:



Conversion time is:



You can see that the difference between the two is 14 hours, and the wrong number is 14 hours later than the correct number. Ben Holmes was deep in thought…

The clouds yellowing

Taking a deep breath, Ben Holmes listed his questions in his mind.

1.” Why do they look up the same database, the same table or even the same field, and the results will be different?”

2.” If not, why not 12 hours, 13 hours, 15 hours, 14 hours?”

Ben Holmes was puzzled, and he repeated the process step by step in his head. “What is different? There must be something different!” “, Ben Holmes suddenly had a flash of inspiration and thought that the common point between the two is that they receive the service provided by the MyBatis server, and only MyBatis will contact this field during the service process and convert it. “Is it MyBatis that manipulates it? So why didn’t it work before?” “, Ben Holmes quickly denied that MyBatis had tamper, but in addition to MyBatis, no one else can do it ah? For a while, the case was shrouded in fog and no progress was made.

“It seems that we have to start with Mybatis, he must conceal something we don’t know”, thinking in his mind, so Ben Holmes found Mybatis and planned to have a deep talk with Mybatis, but Mybatis denied the question of Ben Holmes, and Mybatis said in a short temper: “I said I didn’t do anything! I didn’t!” “For a moment, Ben Holmes and Mybatis fell into a speechless atmosphere. Suddenly, Mybatis said: “Oh, yeah, I’ve been a bit lazy, I’ve delegated all the createTime queries to JDBC, and I’m only responsible for converting the corresponding values to the corresponding types. Is it JDBC that did something to createTime?” .

Ben Holmes flashed. “Why didn’t you say so?” “And then ran to check the monitor. In the monitor named DefaultResultSetHandler, MyBatis was finally verified when fast forward to getPropertyMappingValue:



Then follow the monitor into the datetypeHandler to see:



Ben Holmes smiled confidently at this. He felt that he was getting closer to the truth.



“That’s it, ResultSet!” That’s right, it’s the kind of guy that Ben Holmes and JDBC used to have when they were fighting,

The well-known ResultSet, “So how does it unknowingly replace data?” Ben Holmes continued to look.

The truth

As surveillance deepens, Ben Holmes arrives at the first scene of the crime:



Ben Holmes noticed that there is a StringConverter that contains a valueFactory property:



And this targetVf has a specific type of YearToDateValueFactory:



YeartoDateValueFactory also has a targetVF with the specific instance type:



Then its createFromTimestamp method is called:



Zoom in on the monitoring here:



It turns out that JDBC did something to change the time. We got the time from the database correctly

2021-02-22 11:48:04, but JDBC calls the Calendar.getTimeInMills () method, where the time is changed to

2021-02-23 11:48:04, just 14 hours, then continue to view monitoring:



The isTimeset flag bit is false, so we need to update the time. The process of updating the time is a little bit more complex. To help you understand the reason, let’s first look at the sqlTimeStampValueFactory constructor:



Timezone = CST; Locale = US; TimeZone = CST; TimeZone = CST; Locale = US; TimeZone = CST; TimeZone = CST; Locale = US; TimeZone = CST; We are using MySQL:



Mysql = ‘CST’; Mysql = ‘CST’; Mysql = ‘CST’; Mysql = ‘CST’; And the CST time zone is another magic time zone:

Central Standard Time (USA) -6:00 a.m


Central Standard Time (Australia) UT+9:30


China Standard Time UT+8:00


Cuba Standard Time UT-4:00

As you can see, CST can represent 4 time zones. The default Locale set in JDK8 is US, which means that the time represented by the Calendar in SQLTimestampValueFactory is the time of the West Six Region of Central America. In SqlTimestampValueFactory. CreateFromTimestamp method invoked in the calendar example getTimeInMillis method:



This method calls updateTime(), which in turn calls computeTime() with the following line:



The whole logic of the method computeTime is to get the default time zone of the machine on which the program is running (usually we are Asia/Shanghai), and then update the time represented by the previous Calendar according to this time zone. The time zone represented by the Calendar at this time is W6 Central Time, but now it needs to be updated to Chinese Standard Time. Taking GMT as Standard 0 in the UK, W6 is -6 in the US, while China is at +8 East Zone. Therefore, the time difference between the two is 14 hours, and the time obtained by the program is 14 hours later than the database time.

“Then why isn’t the other program a problem?” At this point, the little brother who reported the case put forward a question

“Simple, because these two programs use different versions of mysql-connector-java”





In previous versions (version mysql-connector-java:5.x and before), the Calendar obtained by default is the current time zone of the system. There is no difference and it will not affect the final result:





This can occur with versions of mysql-connector-java:6.x or above, and one significant difference between mysql-connector-java:5.x and mysql-connector-java:6.x is that, Configure the database driverName differently:

DriverClassName: com.mysql. JDBC.Driver # mysql-connector-java 5.x


DriverClassName: com.mysql.cj.jdbc.Driver # mysql-connector-java 6.x and later

Gorgeous curtain call

“Inspector Ben Holmes. But what shall we do the next time we come across a situation like this?” “Quite simply, now that we know the reason for the 14-hour difference, we can tailor the treatment to the situation.” 1. Modify the program’s database connection string to specify the time zone: > & serverTimeZone =GMT%2B8 2. > set time_zone = ‘+8:00’; > set time_zone = ‘+8:00’;

“If evil were a magnificent and cruel piece of music, I would end it with my own words” “The morning light drains the last line of melancholy and black ink dyed with peace.” With the music, Holmes slumbered to sleep, waiting for the next case….

This article by the blog multiple platform
OpenWriteRelease!