浅谈mysql的timestamp存在的时区问题_Mysql_

简介

众所周知，mysql中有两个时间类型，timestamp与datetime，但当在网上搜索timestamp与datetime区别时，会发现网上有不少与时区有关的完全相反的结论，主要两种：

timestamp没有时区问题，而datetime有时区问题，原因是timestamp是以UTC格式存储的，而datetime存储类似于时间字符串的形式，示例博文：MySQL 中 datetime 和 timestamp 的区别与选择timestamp也有时区问题，示例博文：mysql中timestamp时区的问题

两种观点让人迷惑，那timestamp到底会不会有时区问题呢？

答：因为mysql数据库未指定所在时区默认为美国中部时间
(UTC-06:00)，美国从“3月11日”至“11月7日”实行夏令时，美国中部时间改为 UTC-05:00，与 UTC+08:00 相差 13 小时,冬令时则相差14个小时。所以存储的时候时间就已经有“误差了”。
各位小伙伴使用timestamp类型的时候一定要注意指定时区，不管是在数据库配置指定还是数据库连接的参数设置，一定要指定时区。

serverTimezone=Asia/Shanghai show variables like ‘%time_zone%'; set time_zone='+08:00'; select now();

基本概念

时区：
由于地域的限制，人们发明了时区的概念，用来适应人们在时间感受上的差异，比如中国的时区是东8区，表示为+8:00，或GMT+8，而日本的时区是东9区，表示为+9:00，或GMT+9，当中国是早上8点时，日本是早上9点，即东8区的8点与东9区的9点，这两个时间是相等的。
另外时间还有如下两个概念：

绝对时间：

如unix时间缀，是1970-01-01 00:00:00开始到现在的秒数，如：1582416000，这种表示是绝对时间，不受时区影响，也叫纪元时epoch。

本地时间：

相对于某一时区的时间，是本地时间，比如东8区的2020-02-23 08:00:00，是中国人的本地时间，而在此时，日本人的本地时间是2020-02-23 09:00:00，所以本地时间都是与某一时区相关的，脱离时区看本地时间，是没有意义的，因为你并不知道这具体是指的什么时间点。

比如在Java中，Date对象是绝对时间，通过SimpleDateFormat格式化出来的yyyy-MM-dd HH:mm:ss形式的时间字符串，是本地时间，如果SimpleDateFormat没有调用setTimeZone()显示指定时区，那么默认用的是jvm运行在的操作系统上的时区，我们开发机上的时区基本都是GMT+8。

timestamp与datetime区别

如下，我创建了一张表，里面time_stamp是timestamp类型，date_time是datetime类型，create_timestamp、create_datetime是timestamp与datetime类型，但是它们可以由数据库自动生成。

CREATE TABLE `time_test` ( `id` bigint unsigned, `time_stamp` timestamp, `date_time` datetime, `create_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `create_datetime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) )

1、首先将数据库时区设置为+8:00，即中国的东8区

2、然后如下手动插入一个固定时间的数据，以及用now()函数插入当前时间

3、当插入完数据后，然后我们修改当前会话的时区为+9:00，即日本的东9区，然后再次查看数据

4、如上，定义为timestamp类型的列time_stamp、create_timestamp不管是手动插入的，还是now()函数插入的，东9区都比东8区的时间大1个小时，这是正确的，说明timestamp类型是时区相关的，然而定义为datetime类型的date_time、create_datetime字段，时间都没有变化，这说明datetime类型是时区无关的。

结论：
timestamp在存储上是包含时区的，而datetime是不包含时区，说明网上的第一种说法是对的。

再看个例子
我们将东8区的的2020-02-23 08:00:00转换为unix时间缀（绝对时间），再插入数据库试试？
如下，使用linux的date命令转换时间串为unix时间缀：

$ "date" --date="2020-02-23 08:00:00 +08:00" +%s 1582416000

然后用mysql的()函数，将unix时间缀转换为mysql时间类型来插入数据。

如上，查询出来的时间，也是东9区的9点，时间也是正确的。

为什么网上又说timestamp类型存在时区问题？

我发现网上说timestamp有时区问题，都是应用端插入数据，然后到数据库中去看，结果发现时间不一样，因此我打算在Java中写个Demo试一下，看能不能重现这个问题。

1、首先，下面是Java中Entity的定义，与上面的time_test表对应，注意，这里面时间属性都是用Date类型定义的，如下：

2、然后，我写了两个接口/insert与/queryAll来插入与查询数据，如下：

3、然后我把数据库的时区设置为+09:00时区，即日本的东9区，如下：

4、然后调用/insert接口插入数据，注意我接口传入的时间是东8区的8点，如下：

5、插入完后，去数据库中查询一把，如下：

可以看到，time_stamp字段时间是9点，且我已将数据库时区设置为东9区，东9区的9点与东8区的8点，这两个时间实际是相等的，因此时间数据没错。

6、然后我使用/queryAll接口将数据查询出来，如下：

timeStamp属性是1582416000000，这是毫秒级的时间缀，秒级则是1582416000，对应是东8区的2020-02-23 08:00:00，时间数据也没错！

7、然后我又将mysql时区修改回+8:00，并重启我们的java应用，如下：

8、再查询一下数据，如下：

timeStamp属性还是1582416000000，时间没有变化，这也是正确的。

那为什么网上会说timestamp存在时区问题？

经过一翻查看，我发现他们都提到了jdbc的serverTimezone，会不会是这个配置错误导致的呢？就先试试吧！
1、如图，我把数据库时区修改回+9:00时区，然后故意把jdbc的url上的serverTimezone配置为与数据库不一致的GMT+8时区，然后重启java应用，如下：

url: jdbc:mysql://localhost:3306/testdb?serverTimezone=GMT%2B8&useUnicode=true&characterEncoding=utf8

其中GMT%2B8就是GMT+8，因为在url上需要urlencode，所以就变成了GMT%2B8。

2、重新插入数据，注意插入的时间还是东8区的8点，如下：

3、然后，我再到数据库中查询一把，如下：

time_stamp中时间竟然是8点！要知道我们虽然插入的是东8区的8点，但当前会话可是东9区的，东8区的8点等于东9区的9点，所以正确显示应该为9点才对，时间差了1小时！

4、然后，我又调用/queryAll接口查询了一把，想看看mybatis查询出来的时间数据对不对，如下：

可以看到timeStamp是1582416000000，秒级是1582416000，这个时间就是东8区的8点，东9区的9点啊！查询出来的时间竟然是正确的，为什么？？？

serverTimezone的本质

为了找出问题所在，我调试了一下mysql的jdbc驱动代码，终于弄明白了原因，主要可以看看如下这几点：

1.mysql驱动创建连接后，会调用com.mysql.jdbc.ConnectionImpl#configureTimezone()来配置此连接的时区，如果配置了serverTimezone，则会使用serverTimezone配置的时区，没配置时会去取数据库中的time_zone变量，这就是为什么我们没有配置serverTimezone变量时，结果也是正确的。

//若使用普通驱动，使用此方法配置mysql连接的时区 com.mysql.jdbc.ConnectionImpl#configureTimezone() //若使用cj驱动，使用此方法配置mysql连接的时区 com.mysql.cj.protocol.a.NativeProtocol#configureTimezone()

2.调用jdbc的setTimestamp()方法时，实际调用的是com.mysql.cj.jdbc.ClientPreparedStatement#setTimestamp()，这里面会根据serverTimezone指定的时区，将对应的Timestamp对象转换为serverTimezone指定时区的本地时间字符串。

3.执行sql语句时，会执行com.mysql.cj.jdbc.ClientPreparedStatement#execute()，这里面sendPacket变量保存着真实会发送到mysql的sql语句。

注：看的是8.0.11版本mysql-connector-java驱动源码，不同版本代码会稍有差异，比如5.2.16版本驱动，jdbc url上需要同时配置这两个配置：useTimezone=true&serverTimezone=GMT%2B8，且setTimestamp()对应的是com.mysql.jdbc.PreparedStatement#setTimestampInternal方法。

原理总结如下：
mysql驱动在发送sql前，会将jdbc中的Date对象参数，根据serverTimeZone配置的时区转化为日期字符串后，再发送sql请求给mysql server，同样在mysql server返回查询结果后，结果中的日期值也是日期字符串，mysql驱动会根据serverTimeZone配置的时区，将日期字符串转化为Date对象。

因此，当serverTimeZone与数据库实际时区不一致时，会发生时区转换错误，导致时间偏差，如下：
a、比如sql参数是一个Date对象，时间值是东8区的2020-02-23 08:00:00，注意它里面存储的可不是2020-02-23 08:00:00这个字符串，它是Date对象(绝对时间)，只是我用文字表达出来是东8区的2020-02-23 08:00:00。
b、然后，由于serverTimeZone配置的是东8区，mysql驱动会将这个Date对象转为2020-02-23 08:00:00，注意这时已经是字符串了，然后再将sql发送给mysql，注意这里的sql里面已经将Date参数替换为2020-02-23 08:00:00了，因为Date对象本身是无法走网络的。
c、然后mysql数据库接收到这个时间字符串2020-02-23 08:00:00后，由于数据库时区配置是东9区，它会认为这个时间是东9区的，它会以东9区解析这个时间字符串，这时数据库保存的时间是东9区的2020-02-23 08:00:00，也就是东8区的2020-02-23 07:00:00，保存的时间就偏差了1个小时。
d、查询结果里时间为什么又对了呢，因为查询结果返回了东9区的时间字符串，而java应用又将其理解为是东8区的时间，负负得正了！

将serverTimezone与mysql时区保持一致

so，那么如果我们将serverTimezone配置改正确，即与数据库保持一致时，应该查询到的时间就会是错的，会少1个小时。

1、jdbc url中使用与数据库一样的东9区GMT+9，如下：

url: jdbc:mysql://localhost:3306/testdb?serverTimezone=GMT%2B9&useUnicode=true&characterEncoding=utf8

其中的GMT%2B9，即是GMT+9。

2、然后重启Java应用，再查询一把看看，如下：

提示： 本文由神整理自网络，如有侵权请联系本站删除！
本站声明：
1、本站所有资源均来源于互联网，不保证100%完整、不提供任何技术支持；
2、本站所发布的文章以及附件仅限用于学习和研究目的;不得将用于商业或者非法用途；否则由此产生的法律后果，本站概不负责！