mysql_关于CST和GMT时区时间转换

问题：

今天在往数据库查询一条数据时突然发现插入的时间竟然比系统时间少了13个小时。。。然后因为插入时间的问题延伸出之前写的SQL中只要涉及到创建时间都有可能存在，也就是某月1号插入的数据，你在统计时，当月并未统计，实际上是在上个月的统计数据中。。。。这就尴尬了。。。

排查

1、首先查证测试环境数据库时区：SHOW VARIABLES LIKE ‘%time_zone%’

竟然设置的CST时区，之前不是啊，之后询问主管才得知，当前改造的老项目生产环境的数据库使用的CST。。。为了保证测试一致性，就修改了数据库时区。。。
到此，直接找到时间相差13个小时的原因。。。。

解决

既然知道时间差，也知道时区了，那么问题就好解决了，
mysql中有一个函数CONVERT_TZ() 可以解决这个问题(这里为了更直观，直接贴图)
通过这条SQL查询出来的时间

SELECT report_id,create_time FROM report_item WHERE report_id=2584

结果：

上图中的时间就是CST时区时间，单实际上系统时间是：2021-05-21 10:05:12，相差足足13个小时
所以SQL修改为：

SELECT report_id,CONVERT_TZ(create_time, 'UTC','+13:00') as create_time FROM report_item WHERE report_id=2584

到这里，基本完美解决了时区转换问题，后来度娘了一下这个问题，发现CST和GMT时间相差是13或14小时，至于是13小时还是14小时，取决于你传递给数据库的时间

函数介绍：CONVERT_TZ(dt,from_tz,to_tz)

转换datetime值dt，从 from_tz 由给定转到 to_tz 时区给出的时区，并返回的结果值。 如果参数无效该函数返回NULL。

示例

yyyy-MM-dd格式

SELECT CONVERT_TZ('2021-5-21 15:30:00','UTC','+13:00') AS 北京时间;

这里注意一点，我的SQL时区是CST，但是我在这里用的UTC来作为标准时间，所以可以理解CST-UTC-GMT，所以最后我用了+13:00,这里也可能会有人问为什么不直接用CST来转，这个嘛。。。可能是我mysql版本问题?我直接写CST，竟然返回给我一个null。。。尴尬。。。

使用这样的写法可以解决现在的问题，但是最重要的一点就是从根源上去解决，不要去给数据库设置默认时区，如果一定要，那设置GMT或者UTC都可以，不用使用CST时区，因为这个时区存在很多很多的问题，这里就不意义赘述了。。。大家可以去找度娘要关于CST时区的问题

总结

1、数据库时区最好不要设置成CST，以免出现上面的错误
2、当数据库中的时间用的是时间类型时候，Java中可以用String，但是这种做法不是很国际化
3、在数据库连接字符串中设置时区。推荐这种方式，如下：

jdbc:mysql://xxxx:3306/table_name?serverTimezone=Asia/ShanghaiallowMultiQueries=true&useUnicode=true&characterEncoding=UTF-8

如果对你有所帮助，点个赞吧