mysql时区问题

背景

插入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...