背景

插入timestamp类型与datetime类型数据比预计后果早14小时

起因

如果说相差8小时不够让人诧异，那相差13小时可能会让很多人摸不着头脑。呈现这个问题的起因是JDBC与MySQL对 “CST” 时区协商不统一。因为CST时区是一个很凌乱的时区，有四种含意：

  • 美国中部工夫 Central Standard Time (USA) UTC-05:00或UTC-06:00
  • 澳大利亚中部工夫 Central Standard Time (Australia) UTC+09:30
  • 中国规范时 China Standard Time UTC+08:00
  • 古巴规范时 Cuba Standard Time UTC-04:00

MySQL中，如果time_zone为默认的SYSTEM值，则时区会继承为零碎时区CST，MySQL外部将其认为是UTC+08:00。而jdbc会将CST认为是美国中部工夫，这就导致会相差13小时，如果处在冬令时还会相差14个小时。

解决方案

解决此问题的办法也很简略，咱们能够明确指定MySQL数据库的时区，不应用引发误会的CST，能够将time_zone改为'+8:00'，同时jdbc连贯串中也能够减少serverTimezone=Asia/Shanghai。
如何防止上述时区问题，可能你心里也有了些办法，简要总结几点如下：

  1. 首先保证系统时区精确。
  2. jdbc连贯串中指定时区，并与数据库时区统一。
  3. time_zone参数倡议设置为'+8:00'，不应用容易误会的CST。
  4. 各环境数据库实例时区参数放弃雷同。

拓展常识

设置时区办法1
查看时区 show variables like '%time_zone%';
设置以后会话时区 set time_zone='+8:00'，只对本次会话无效，会话完结后，生效。
设置全局会话时区 set global time_zone='+8:00',永恒无效
设置立刻失效 flush privileges
设置时区办法2
通过批改配置文件，重启mysql后永恒无效
https://www.cnblogs.com/jiadi...
数据库参数信息：
全局参数system_time_zone：
零碎时区，在MySQL启动时会查看以后零碎的时区并依据零碎时区设置全局参数system_time_zone的值。

全局参数time_zone：
用来设置每个连贯会话的时区，默认为system时，应用全局参数system_time_zone的值。
数据库连贯参数：
serverTimeZone：
此参数设置时会抉择time_zone ,为设置则应用数据库系统时区。

MySQL：datetime与timestamp的区别及应用抉择
https://majing.io/posts/10000...
参考：
https://www.cnblogs.com/gaoga...
https://www.cnblogs.com/smile...
https://blog.csdn.net/qq_3110...
https://www.cnblogs.com/jiadi...
https://segmentfault.com/a/11...
https://www.zhetao.com/conten...
http://www.mamicode.com/info-...
https://www.cnblogs.com/july-...
https://blog.csdn.net/vae1314...
https://blog.csdn.net/weixin_...
https://www.cnblogs.com/kunji...