疑云初现

  "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';

  "如果邪恶 是华丽残酷的乐章 它的终场 我会 亲手写上"
  "晨曦的光 风干最后一行忧伤 黑色的墨 染上安详"
  伴随着音乐，福尔摩斯悠悠睡去，静待下一桩案件的到来....

出处：https://www.cnblogs.com/wukongbubai/p/14466892.html