问题背景
今天碰到一个问题，就是mysql插入时打印的数据日志时间是正常的，但是插入到数据库时，时间就变了，变成了美东时间。具体变现为
而数据库查询结果如下
很明显，变成了9月17号21:50。
问题分析
其实一开始，没找elk的mybatis插入日志的时候，我是怀疑是java获取到的时间不对，也就是可能是服务器时间问题。但是又不能直接查服务器时间，因为进不去容器。所以就想到查插入的入参日志。
从入参日志可以看到我们获取到的时间是没问题的。所以排除服务器时间问题。那这个时候问题就出在数据库服务器了。
首先 show vari likeables like '%time_zone%';
可以明显看到是CST。CST在mysql是可以表示四种时区，分别是
1.美国中部时间 Central Standard Time (USA) UTC-06:00
2.澳大利亚中部时间 Central Standard Time (Australia) UTC+09:30
3.中国标准时 China Standard Time UTC+08:00
4.古巴标准时 Cuba Standard Time UTC-04:00
所以问题可能就是数据库时区不对。所以解决方案，就是连接语句加上正确的时区
&serverTimezone=Asia/Shanghai到此其实问题就已经解决了。
但是吧，这时候同事说，他们的之前用都是正常的。所以，他们使用的时候为啥正常，肯定有原因，那就找呗。
首先，看下是否是在数据库连接语句上有加时区入参。发现没有
再者，看下java bean config是否有特殊设置。发现没有
后面，发现他们用的是timestamp而我用的是datetime。那会不会是这个原因呢。
首先我把开发环境（和线上的包一毛一样）的datetime，改为timestamp。结果发现不行，时间还是错的。
然后我回到测试环境，发现即时是datetime，时间也是对的。到底为啥呢(带上痛苦面具)
然后吧，我就忽然在网上看到了驱动这两字。我在想是不是驱动问题。
于是我把开发环境的驱动改成测试环境的，一试，果然是驱动问题。
接着看下驱动代码：
上图是测试环境的驱动，可以看到当连接语句没有设置timezone他取了本地jdk的默认timezone进行了设置。
这是开发环境的驱动，可以看到，他取了服务器的timezone进行了设置。
所以这就是为啥测试环境可以，开发和线上不行。但是又有一个问题，就是同事的驱动是5.1.35的为啥也可以，然后我就看了下源码，发现他也是取得本地timezone的。
结论：别乱升级驱动版本
评论