（mysql时间差13个小时）记录：在SSM框架的后端中把java数据类型timestamp插入到mysql数据库数据类型datetime晚13或14个小时的综合分析及解决过程

问题描述：

time:2018-6-3 15:00 

author:[email protected] 鞠政

场景:数据库的时间插入

具体描述： 在用户注册时会调用VipServie的 insert函数语句：           

Date date=new Date();

Timestamp timestamp = new Timestamp(date.getTime())；

vip.setCreateTime(newDate());//此时数据库的时间存的是DateTime类型

    进行用户时间的插入。

但在实际使用过程中，发现实际插入时间比北京时间少了13个小时。

经分析，插入的时间为美国夏令时。

初步怀疑是tomcat/mysql/linux系统时区的问题。

详细解决过程：

1.liunx

linux时区正确排除

2.tomcat

用postman测试---把war放在在本地的tomcat和测试云服务器的tomcat进行测试时，发现时间正确

使我误以为是tomcat设置问题，但通过咨询cc大佬发现tomcat配置未改动

同时，在catalina.sh 第一行家一下一下脚本，设置tomcat时区为东8区

JAVA_OPTS="$JAVA_OPTS-Dfile.encoding=UTF8  -Duser.timezone=GMT+08"

重启tomcat发现错误依旧存在，排除

3.mysql&&jdbc

①开始时，在利用curtime();查看mysql时区时，显示的是正确的东8时区，

但实际该函数调用的是Linux系统的时间，非mysql数据库的时间。

②通过语句：

set globaltime_zone = '+08:00';

set time_zone ='+08:00';

flush privileges;

进行mysql时区的更改，

systemctl status mysqld

systemctl restartmysqld

重启mysql服务

发现依旧错误

③ 在/etc/my.cnf下的【mysql】插入语句

default-time-zone = '+08:00'

重启后发现mysql进不去，经分析应放在【mysqld】下插入，强制设置mysql服务时区为东8区。

重启后测试，成功。

④：成功后，分析出错原因是因为数据库驱动无法判定时区，由此对存入mysql数据库的timestamp类型的数据进行自动时区转换。

4.其他可能的解决方案：

（1）修改mysql数据库注册时间由datetime类型为varchar类型（存储之前转为string类型）；

（2）通过long t =System.currentTimeMillis();

SimpleDateFormat Sd = newSimpleDateFormat("yyyy-MM-dd HH:mm");

Sd.setTimeZone(TimeZone.getTimeZone("GMT+8:00"));

vip.setCreateTime(Sd.format(t));

进行获取时间并存储

（3）driver=com.mysql.jdbc.Driver

url=jdbc\:mysql\://192.168.164.129\:3306/test?useSSL\=false&useUnicode\=true&characterEncoding\=utf8&autoReconnect\=true&serverTimezone\=Hongkong 

在url中serverTimezone()标明时区

 

参考资料：https://blog.csdn.net/qq_22985751/article/details/80239784

https://blog.csdn.net/h996666/article/details/78782423

https://www.liaoxuefeng.com/article/0014132675721847f569c3514034f099477472c73b5dee2000

https://segmentfault.com/q/1010000010791397