疑云初现
"1983年小巷，12月晴朗，夜的第七章，打字机继续推向，接近事实的那下一行"
耳边传来动听的音乐声，双眼微眯，本·福尔摩斯正沉浸在音乐描绘的场景中，忽然耳边响起一阵叮铃叮铃的清脆响声，原来是电话响了，本·福尔摩斯立马回过神来，"看来是案子上门了"，本·福尔摩斯心想，然后接起电话，电话的那头，急切的声音传来：
"喂，请问是本·福尔摩斯探长吗?我们这里发生了一件奇怪的案子，需要您来查探一下"。
挂断电话，本·福尔摩斯火速赶往现场。抵达现场后，联系福尔摩斯的小兄弟立马汇报了情况，"探长，我们这里出现了一件奇怪的案子，是这样的，我们有两个应用，使用的都是同一个数据库，查同样的表的同样的字段，但是两个应用的接口返回的结果截然不同，其中一个接口返回的是正确的时间戳，另一个接口返回的是错误的时间戳，并且两个时间戳时差为14小时"
本·福尔摩斯捋了一捋，"哦？这么奇怪？我来看一看呢"，然后福尔摩斯开始还原现场。首先查看了数据库：
然后查看了正确的返回：
换算成时间是：
和数据库相符，再来看一下错误的返回：
换算成时间是：
可以看到两者之间的确差了14个小时，并且是错误的数据比正确的数据要晚14个小时。此时本·福尔摩斯陷入了深深的沉思...
疑云丛丛
深深的吸了一口气，本·福尔摩斯在脑海中列出了自己的疑问：
1."为什么两者查的是同一个库同一张表甚至同一个字段，结果会不一样呢？"
2."就算不一样，那为何不是差12小时，13小时，15小时，偏偏是14小时呢？"
本·福尔摩斯百思不得其解，他一步一步的脑海中重复这个过程，"到底是哪里不一样呢？肯定是有哪里不一样！"，忽然本·福尔摩斯灵光一闪，想到这两者的共同点都是接收了Mybatis服务员提供的服务，而只有Mybatis在服务过程中会接触到这个字段，并且将其转换，"难道是Mybatis动了手脚？那为什么之前都没问题呢？"，本·福尔摩斯很快否定了Mybatis动了手脚，但是除了Mybatis，也没有其他人可以动手脚了啊？一时间，案子陷入了层层迷雾中，毫无进展。
"看来还是得从Mybatis入手，他肯定隐瞒了一些我们不知道的事"，心里如是想，于是本·福尔摩斯找到了Mybatis，打算和Mybatis深入谈谈，但是Mybatis对本·福尔摩斯的疑问矢口否认，Mybatis脾气暴躁的说："我说了我没有做任何手脚！我没有！"，一时间，本·福尔摩斯和Mybatis陷入了一种无言的氛围，忽然，Mybatis说："咦，对了，我其实一直都比较懒，对createTime的查询这些我都委托给JDBC去处理了，处理完了我只是负责把对应的值转换为对应的类型，会不会是JDBC对createTime动了手脚？"。
本·福尔摩斯精光一闪，"你为什么不早说呢？"，然后匆匆跑去查看监控，在命名为DefaultResultSetHandler的监控里，终于在快进到getPropertyMappingValue时验证了Mybatis的说法：
再跟随监控进入DateTypeHandler查看：
看到这里，本·福尔摩斯自信一笑，他感觉正在接近事实的真相：
"原来是它，ResultSet！"，没错，它就是当初本·福尔摩斯和JDBC大战时，经常会遇到的对手，
大名鼎鼎的ResultSet结果集，"那它又是怎样神不知鬼不觉的把数据替换掉的呢？"本·福尔摩斯继续查看。
真相大白
跟着监控层层深入，本·福尔摩斯来到了犯案的第一现场：
本·福尔摩斯注意到，这里有一个stringConverter，包含一个ValueFactory属性：
而这个targetVf的具体类型为YearToDateValueFactory：
YearToDateValueFactory也有一个targetVf，其具体的实例类型为：
然后会调用其createFromTimestamp方法：
这里放大监控看一下：
原来如此，原来真的是JDBC做了手脚，把时间改了，我们从数据库正确获取到了时间是
2021-02-22 11：48：04，但是JDBC调用了calendar.getTimeInMills()方法，在该方法中把时间改成了
2021-02-23 11：48：04，正好差了14个小时，再继续查看监控：
原来这里，isTimeSet标志位为false，所以要更新时间，至于这个更新时间的过程，比较复杂，本·福尔摩斯为了照顾各位看官的感受，直接讲原因，首先来看SqlTimestampValueFactory的构造方法：
初始化时，calendar为null，会根据传入的TimeZone去初始化一个Calendar，此时TimeZone为CST，Locale为US，直接说，这里的TimeZone是Mybatis从数据库的默认时区获取的，我们使用Mysql：
很好理解，Mysql使用的时区是随系统时区，而对应的系统时区为CST，因此Mysql默认会使用CST时区，这就是为什么SqlTimestampValueFactory构造方法中传入的TimeZone为CST，而CST时区又是一个神奇的时区：
美国中部时间：Central Standard Time (USA) UT-6:00
澳大利亚中部时间：Central Standard Time (Australia) UT+9:30
中国标准时间：China Standard Time UT+8:00
古巴标准时间：Cuba Standard Time UT-4:00
可以看到，CST能表示4个时区，而JDK8源码中默认设置的Locale为US，则代表SqlTimestampValueFactory中的Calendar代表的时间为美国中部西六区的时间，而在SqlTimestampValueFactory.createFromTimestamp方法中调用了该calendar实例getTimeInMillis方法：
而该方法调用updateTime()，又调用computeTime()方法，其中有这么一行代码：
computeTime方法的整个逻辑就是，获取程序运行的机器的默认时区（一般我们都是东八区Asia/Shanghai），然后根据该时区，更新之前的calendar代表的时间，而根据之前的分析我们知道，此时的calendar代表的时区是美国中部时间西六区，而现在需要更新为中国标准时间，以英国格林威治时间为标准0时，美国西六区-6，而中国处于东八区+8，因此两个时间差为14小时，并且是程序得到的时间晚于数据库时间14小时。
"那为什么另外一个程序却没有问题呢？"此时，报案的小兄弟提出了一个疑问
"很简单，因为这两个程序使用的mysql-connector-java的版本不同"
早期版本(版本号为mysql-connector-java:5.x及以前)的代码实现中获取的calendar默认就是系统当前时区，不存在不同的情况，自然不会影响最后的结果：
如果是mysql-connector-java:6.x 及以上的版本，则会出现这种时差问题，另外mysql-connector-java:5.x 和mysql-connector-java:6.x的一个显著区别是，配置的数据库的driverName不同：
driverClassName: com.mysql.jdbc.Driver # mysql-connector-java 5.x及之前版本中的
driverClassName: com.mysql.cj.jdbc.Driver # mysql-connector-java 6.x及后续版本中的
华丽谢幕
"不愧是本·福尔摩斯探长，手到擒来，那我们下次再遇到这种情况应该如何解决呢？"
"很简单，既然我们知道了差14小时的原因，我们就能对症下药了，具体根据实际情况选择"
1.修改程序的数据库连接串，指定时区：
> &serverTimezone=GMT%2B8
2.修改数据库的时区，使数据库时区和程序运营时的默认时区相同：
> set time_zone = '+8:00';
"如果邪恶 是华丽残酷的乐章 它的终场 我会 亲手写上"
"晨曦的光 风干最后一行忧伤 黑色的墨 染上安详"
伴随着音乐，福尔摩斯悠悠睡去，静待下一桩案件的到来....
本文由博客一文多发平台 OpenWrite 发布！
