共事反馈一个问题：Mybatis插入数据库的工夫是昨天的，是不是因为生成Mybatis逆向工程生成的代码有问题？
大家都晓得，对于这类Bug自己是很感兴趣的。直觉通知我，应该不是Mybatis的Bug，很可能是时区的问题。
很好，明天又能够带大家一起来排查Bug了，看看从这次的Bug排查中你能Get什么技能。
这次钻研的问题有点深奥，但论断很重要。Let's go!
问题猜测
共事反馈问题的时候，带了本人的猜测：是不是数据库字段设置为datetime导致？是不是Mybatis逆向工程生成的代码中类型不统一导致的？
共事还要把datetime改为varchar……马上被我禁止了，说：先排查问题，再说解决方案，下午我也抽时间看看。
问题核查
第一步，查看数据库字段类型，是datetime的，没问题。
第二步，查看实体类中类型，是java.util.Date类型，没问题。
第三步，Bug复现。
在Bug复现这一步，用到了单元测试。话说之前还跟敌人探讨过单元测试的魅力，当初自己是越来越喜爱单元测试了。
我的项目基于Spring Boot的，单元测试如下（代码已脱敏）：
@SpringBootTestclass DateTimeTests { @Resource private UserMapper userMapper; @Test public void testDate(){ User user = new User(); // 省略其余字段 user.setCreateDate(new Date()); userMapper.insertSelective(user); }}执行单元测试，查看数据库中插入的数据。Bug复现，工夫确实是前一天的，与以后工夫相差14个小时。
通过下面三步的排查，核实了数据库字段和代码中类型没问题。单元测试也复现了问题，共事没有坑骗我，总要眼见为实，哈哈~
于是根本确定是时区问题。
时区排查
查看服务器工夫
登录测试服务器，执行date命令，查看服务器工夫和时区：
[root@xxx ~]# date2021年 11月 25日 星期四 09:26:25 CST[root@xxx ~]# date -RThu, 25 Nov 2021 09:33:34 +0800显示工夫是以后工夫，采纳CST工夫，最初的+0800，即东8区，没问题。
查看数据库时区
连贯数据库，执行show命令：
show variables like '%time_zone%';+----------------------------+|Variable | Value |+----------------------------+|system_time_zone |CST ||time_zone |SYSTEM |system_time_zone：全局参数，零碎时区，在MySQL启动时会查看以后零碎的时区并依据零碎时区设置全局参数system_time_zone的值。值为CST，与零碎工夫的时区统一。
time_zone：全局参数，设置每个连贯会话的时区，默认为SYSTEM，应用全局参数system_time_zone的值。
查看代码中时区
在单元测试的办法内再增加打印时区的代码：
@Test public void testDate(){ System.out.println(System.getProperty("user.timezone")); User user = new User(); // 省略其余字段 user.setCreateDate(new Date()); userMapper.insertSelective(user); }打印的时区为：
Asia/Shanghai也就是说Java中应用的是UTC时区进行业务逻辑解决的，也是东八区的工夫。
那么问题到底出在哪里呢？
问题根本出现
通过上述排查，基本上确定是时区的问题。这里，再补充一下上述相干的时区知识点。
UTC工夫
UTC工夫：世界协调工夫（UTC）是世界上不同国家用来调节时钟和工夫的次要工夫规范，也就是零时区的工夫。
UTC, Coordinated Universal Time是一个规范，而不是一个时区。UTC 是一个全球通用的工夫规范。寰球各地都批准将各自的工夫进行同步协调 (coordinated)，这也是UTC名字的起源：Universal Coordinated Time。
CST工夫
CST工夫：中央标准工夫。
CST能够代表如下4个不同的时区：
- 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，古巴
再次剖析
很显然，这里与UTC工夫无关，它只是工夫规范。目前Mysql中的system_time_zone是CST，而CST能够代表4个不同的时区，那么，Mysql把它当做哪个时区进行解决了呢？
简略推算一下，中国工夫是UT+8:00，美国是 UT-6:00，当传入中国工夫，间接转换为美国工夫（未思考时区问题），工夫便慢了14个小时。
既然晓得了问题，那么解决方案也就有了。
解决方案
针对上述问题可通过数据库层面和代码层面进行解决。
计划一：批改数据库时区
既然是Mysql了解错了CST指定的时区，那么就将其设置为正确的。
连贯Mysql数据库，设置正确的时区：
[root@xxxxx ~]# mysql -uroot -pmysql> set global time_zone = '+8:00';mysql> set time_zone = '+8:00'mysql> flush privileges;再次执行show命令：
show variables like '%time_zone%';+----------------------------+|Variable | Value |+----------------------------+|system_time_zone |CST ||time_zone |+08:00 |能够看到时区曾经成为东八区的工夫了。再次执行单元测试，问题失去解决。
此种计划也能够间接批改MySQL的my.cnf文件进行指定时区。
计划二：批改数据库连贯参数
在代码连贯数据库时，通过参数指定所应用的时区。
在配置数据库连贯的URL前面增加上指定的时区serverTimezone=Asia/Shanghai：
url: jdbc:mysql://xx.xx.xx.xx:3306/db_name?useUnicode=true&characterEncoding=utf8&autoReconnect=true&serverTimezone=Asia/Shanghai再次执行单元测试，问题同样能够失去解决。
问题完了？
通过上述剖析与操作，时区的问题曾经解决了。问题就这么完事了吗？为什么是这样呢？
为了验证时区问题，在时区谬误的数据库中，创立了一个字段，该字段类型为datetime，默认值为CURRENT_TIMESTAMP。
那么，此时插入一条记录，让Mysql主动生成该字段的工夫，你猜该字段的工夫是什么？中国工夫。
神奇不？为什么同样是CST时区，零碎主动生成的工夫是正确的，而代码插入的工夫就有时差问题呢？
到底是Mysql将CST时区了解为美国工夫了，还是Mybatis、连接池或驱动程序将其了解为美国工夫了？
重头戏开始
为了追究到底是代码中哪里出了问题，先开启Mybatis的debug日志，看看insert时是什么值：
2021-11-25 11:05:28.367 [|1637809527983|] DEBUG 20178 --- [ scheduling-1] c.h.s.m.H.listByCondition : ==> Parameters: 2021-11-25 11:05:27(String), 0(Integer), 1(Integer), 2(Integer), 3(Integer), 4(Integer)下面是insert时的参数，也就是说在Mybatis层面工夫是没问题的。排除一个。
那是不是连接池或驱动程序的问题？连接池自身来讲跟数据库连贯的具体操作关系不大，就间接来排查驱动程序。
Mybatis是xml中定义日期字段类型为TIMESTAMP，扒了一下mysql-connector-Java-8.0.x的源码，发现SqlTimestampValueFactory是用来解决TIMESTAMP类型的。
在SqlTimestampValueFactory的构造方法上打上断点，执行单元测试：
能够明确的看到，Calendar将时区设置为Locale.US，也就是美国工夫，时区为CST，offset为-21600000。-21600000单位为毫秒，转化为小时，恰好是“-6:00”，这与北京工夫“GMT+08:00”恰好相差14个小时。
于是一路往上最终追溯调用链路，该TimeZone来自NativeServerSession的serverTimeZone，而serverTimeZone的值是由NativeProtocol类的configureTimezone办法设置的。
public void configureTimezone() { String configuredTimeZoneOnServer = this.serverSession.getServerVariable("time_zone"); if ("SYSTEM".equalsIgnoreCase(configuredTimeZoneOnServer)) { configuredTimeZoneOnServer = this.serverSession.getServerVariable("system_time_zone"); } String canonicalTimezone = getPropertySet().getStringProperty(PropertyKey.serverTimezone).getValue(); if (configuredTimeZoneOnServer != null) { // user can override this with driver properties, so don't detect if that's the case if (canonicalTimezone == null || StringUtils.isEmptyOrWhitespaceOnly(canonicalTimezone)) { try { canonicalTimezone = TimeUtil.getCanonicalTimezone(configuredTimeZoneOnServer, getExceptionInterceptor()); } catch (IllegalArgumentException iae) { throw ExceptionFactory.createException(WrongArgumentException.class, iae.getMessage(), getExceptionInterceptor()); } } } if (canonicalTimezone != null && canonicalTimezone.length() > 0) { // 此处设置TimeZone this.serverSession.setServerTimeZone(TimeZone.getTimeZone(canonicalTimezone)); if (!canonicalTimezone.equalsIgnoreCase("GMT") && this.serverSession.getServerTimeZone().getID().equals("GMT")) { throw ExceptionFactory.createException(WrongArgumentException.class, Messages.getString("Connection.9", new Object[] { canonicalTimezone }), getExceptionInterceptor()); } } }debug跟踪一下上述代码，显示信息如下：
至此，通过canonicalTimezone值的获取，能够看出URL前面配置serverTimezone=Asia/Shanghai的作用了。其中，下面第一个代码块获取time_zone的值，第二个代码块中获取system_time_zone的值。这与查询数据库取得的值统一。
因为出问题时并未在url中增加参数serverTimezone=Asia/Shanghai，所以走canonicalTimezone为null的状况。随后逻辑中调用了TimeUtil.getCanonicalTimezone办法：
public static String getCanonicalTimezone(String timezoneStr, ExceptionInterceptor exceptionInterceptor) { if (timezoneStr == null) { return null; } timezoneStr = timezoneStr.trim(); // handle '+/-hh:mm' form ... if (timezoneStr.length() > 2) { if ((timezoneStr.charAt(0) == '+' || timezoneStr.charAt(0) == '-') && Character.isDigit(timezoneStr.charAt(1))) { return "GMT" + timezoneStr; } } synchronized (TimeUtil.class) { if (timeZoneMappings == null) { loadTimeZoneMappings(exceptionInterceptor); } } String canonicalTz; if ((canonicalTz = timeZoneMappings.getProperty(timezoneStr)) != null) { return canonicalTz; } throw ExceptionFactory.createException(InvalidConnectionAttributeException.class, Messages.getString("TimeUtil.UnrecognizedTimezoneId", new Object[] { timezoneStr }), exceptionInterceptor); }上述代码中最终走到了loadTimeZoneMappings(exceptionInterceptor);办法：
private static void loadTimeZoneMappings(ExceptionInterceptor exceptionInterceptor) { timeZoneMappings = new Properties(); try { timeZoneMappings.load(TimeUtil.class.getResourceAsStream(TIME_ZONE_MAPPINGS_RESOURCE)); } catch (IOException e) { throw ExceptionFactory.createException(Messages.getString("TimeUtil.LoadTimeZoneMappingError"), exceptionInterceptor); } // bridge all Time Zone ids known by Java for (String tz : TimeZone.getAvailableIDs()) { if (!timeZoneMappings.containsKey(tz)) { timeZoneMappings.put(tz, tz); } } }该办法加载了配置文件"/com/mysql/cj/util/TimeZoneMapping.properties"外面的值，通过转换，timeZoneMappings中，对应CST的为"CST"。
最终失去canonicalTimezone为“CST”，而TimeZone取得是通过TimeZone.getTimeZone(canonicalTimezone)办法取得的。
也就是说TimeZone.getTimeZone("CST")的值为美国工夫。写个单元测试验证一下：
public class TimeZoneTest { @Test public void testTimeZone(){ System.out.println(TimeZone.getTimeZone("CST")); }}打印后果：
sun.util.calendar.ZoneInfo[id="CST",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=CST,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]很显然，该办法传入CST之后，默认是美国工夫。
至此，问题起因根本清朗：
- Mysql中设置的server_time_zone为CST，time_zone为SYSTEM。
- Mysql驱动查问到time_zone为SYSTEM，于是应用server_time_zone的值，为”CST“。
- JDK中TimeZone.getTimeZone("CST")取得的值为美国时区；
- 以美国时区结构的Calendar类；
- SqlTimestampValueFactory应用上述Calendar来格式化零碎获取的中国工夫，时差问题便呈现了；
- 最终反映在数据库数据上就是谬误的工夫。
serverVariables变量
再延长一下，其中server_time_zone和time_zone都来自于NativeServerSession的serverVariables变量，该变量在NativeSession的loadServerVariables办法中进行初始化，要害代码：
if (versionMeetsMinimum(5, 1, 0)) { StringBuilder queryBuf = new StringBuilder(versionComment).append("SELECT"); queryBuf.append(" @@session.auto_increment_increment AS auto_increment_increment"); queryBuf.append(", @@character_set_client AS character_set_client"); queryBuf.append(", @@character_set_connection AS character_set_connection"); queryBuf.append(", @@character_set_results AS character_set_results"); queryBuf.append(", @@character_set_server AS character_set_server"); queryBuf.append(", @@collation_server AS collation_server"); queryBuf.append(", @@collation_connection AS collation_connection"); queryBuf.append(", @@init_connect AS init_connect"); queryBuf.append(", @@interactive_timeout AS interactive_timeout"); if (!versionMeetsMinimum(5, 5, 0)) { queryBuf.append(", @@language AS language"); } queryBuf.append(", @@license AS license"); queryBuf.append(", @@lower_case_table_names AS lower_case_table_names"); queryBuf.append(", @@max_allowed_packet AS max_allowed_packet"); queryBuf.append(", @@net_write_timeout AS net_write_timeout"); queryBuf.append(", @@performance_schema AS performance_schema"); if (!versionMeetsMinimum(8, 0, 3)) { queryBuf.append(", @@query_cache_size AS query_cache_size"); queryBuf.append(", @@query_cache_type AS query_cache_type"); } queryBuf.append(", @@sql_mode AS sql_mode"); queryBuf.append(", @@system_time_zone AS system_time_zone"); queryBuf.append(", @@time_zone AS time_zone"); if (versionMeetsMinimum(8, 0, 3) || (versionMeetsMinimum(5, 7, 20) && !versionMeetsMinimum(8, 0, 0))) { queryBuf.append(", @@transaction_isolation AS transaction_isolation"); } else { queryBuf.append(", @@tx_isolation AS transaction_isolation"); } queryBuf.append(", @@wait_timeout AS wait_timeout"); NativePacketPayload resultPacket = sendCommand(this.commandBuilder.buildComQuery(null, queryBuf.toString()), false, 0); Resultset rs = ((NativeProtocol) this.protocol).readAllResults(-1, false, resultPacket, false, null, new ResultsetFactory(Type.FORWARD_ONLY, null)); Field[] f = rs.getColumnDefinition().getFields(); if (f.length > 0) { ValueFactory<String> vf = new StringValueFactory(this.propertySet); Row r; if ((r = rs.getRows().next()) != null) { for (int i = 0; i < f.length; i++) { this.protocol.getServerSession().getServerVariables().put(f[i].getColumnLabel(), r.getValue(i, vf)); } } }在上述StringBuilder的append操作中，有"@@time_zone AS time_zone"和"@@system_time_zone AS system_time_zone"两个值，而后查询数据库，从数据库取得值之后，put到serverVariables中。
再来debug一下：
能够看出system_time_zone的值为CST。
同样time_zone的值为“SYSTEM”。
依据代码中的提醒，拼接与代码一样的SQL查问一下数据库：
select @@time_zone;SYSTEM值确实是“SYSTEM”。此时，咱们又得出另外一个查问Mysql以后时区的办法。
至此，该问题的排查完满收官。大出一口气~~~
小结
在上述问题排查的过程中，屡次用到单元测试，这也是单元测试的魅力所在，用最简略的代码，最轻量的逻辑，最节省时间的形式来验证和追踪谬误。
再回顾一下上述Bug排查中用到和学到的知识点：
- Linux日期查看，时区查看及衍生如何配置时区；
- Mysql时区查看；
- Spring Boot单元测试；
- Java时区获取；
- UTC工夫和CST工夫；
- 两种解决时区问题的计划；
- 浏览、debug Mysql驱动源代码；
- TimeZone.getTimeZone("CST")默认时区为美国时区；
- Mysql驱动中解决时区问题根本流程逻辑；
- Mybatis debug日志相干打印；
- 其余相干常识。
通过本篇Bug查找的文章，你学到了什么？如果有那么一点启发，不要悭吝，给点个赞吧！
博主简介：《SpringBoot技术底细》技术图书作者，热爱钻研技术，写技术干货文章。
公众号：「程序新视界」，博主的公众号，欢送关注~
技术交换：请分割博主微信号：zhuan2quan
<center>“程序新视界”，一个100%技术干货的公众号</center>