原文地址php
当JVM时区和数据库时区不一致的时候,会发生什么?这个问题也许你历来没有注意过,可是当把Java程序容器化的时候,问题就浮现出来了,由于目前几乎全部的Docker Image的时区都是UTC。本文探究了MySQL及其JDBC驱动对于时区的处理方式,并尝试给出最佳实践。html
DATE
和TIME
类型不支持时区转换。对于TIMESTAMP
类型,MySQL会正确的根据connection时区(对于JDBC来讲就是JVM时区)/服务端时区作转换。java
DATE_FORMAT()
),由于返回的结果是服务端的时区,而不是connection的时区(对于JDBC来讲就是JVM时区)。CURRENT_TIMESTAMP()
, CURRENT_TIME()
, CURRENT_DATE()
能够安全的使用,返回的结果会转换成connection时区(对于JDBC来讲就是JVM时区)。CURRENT_TIME()
有一个不知道是否是BUG的Bug #92453。MySQL - The DATE, DATETIME, and TIMESTAMP Types:mysql
MySQL convertsTIMESTAMP
values from the current time zone to UTC for storage, and back from UTC to the
current time zone for retrieval. (This does not occur for other types such asDATETIME
.)
By default, the current time zone for each connection is the server's time. The time zone can be set on
a per-connection basis.
As long as the time zone setting remains constant, you get back the same value you store.
If you store aTIMESTAMP
value, and then change the time zone and retrieve the value, the retrieved value
is different from the value you stored. This occurs because the same time zone was not used for conversion
in both directions.
简而言之就是两句话:git
TIMESTAMP
类型所返回的值,会根据connection的时区(对于JDBC来讲就是JVM时区)作转换TIMESTAMP
类型会作时区转换为了验证这个结论,我写了一段程序来实验,这个程序作了三件事情:github
Asia/Shanghai
时区构造一个日期java.util.Date
:2018-09-14 10:00:00
,而后插入到数据库里(表:test,列:timestamp类型)Asia/Shanghai
时区把这个值再查出来,看看结果。Asia/Shanghai
时区,得到这个字段的格式化字符串(使用DATE_FORMAT()
函数)。Europe/Paris
时区重复第2-3步的动做在运行程序以前,咱们先用Docker启动一个MySQL,它所在的MySQL的时区是UTC(除非特别设定,全部Docker Image时区都默认为UTC):sql
docker run --name mysql-timezone-test \ -e MYSQL_RANDOM_ROOT_PASSWORD=yes \ -e MYSQL_DATABASE=testdb \ -e MYSQL_USER=tz \ -e MYSQL_PASSWORD=tz \ -p 3306:3306 \ -d mysql:8
下面是结果:docker
Insert data, Time Zone : 中国标准时间 java.util.Date : 2018-09-14 10:00:00 Insert into timestamp column : 2018-09-14 10:00:00 -------------------- Retrieve data, Time Zone : 中国标准时间 Retrieve java.util.Date : 2018-09-14 10:00:00 Retrieve formatted string : 2018-09-14 02:00:00 -------------------- Retrieve data, Time Zone : 中欧时间 Retrieve java.util.Date : 2018-09-14 04:00:00 Retrieve formatted string : 2018-09-14 02:00:00
能够看到Retrieve java.util.Date
返回的结果根据JVM时区作了转换的。而Retrieve formatted string
返回的结果则是UTC时间。数据库
MySQL与"当前日期时间"相关的函数有这么些,MySQL - Date and Time Functions:安全
TheCURRENT_TIMESTAMP()
,CURRENT_TIME()
,CURRENT_DATE()
, andFROM_UNIXTIME()
functions return values
in the connection's current time zone, which is available as the value of the time_zone system variable.
并且根据文档所讲,它们返回的结果匹配当前链接所设定的时区。
为了验证这个结论,一样写了一段程序,分别使用Asia/Shanghai
和Europe/Paris
来调用CURRENT_TIMESTAMP()
、CURRENT_TIME()
、CURRENT_DATE()
。
下面是运行结果:
JVM Time Zone : 中国标准时间 Test CURRENT_DATE() : 2018-09-18 Test CURRENT_TIME() : 10:55:41 Test CURRENT_TIMESTAMP() : 2018-09-18 10:55:41.0 -------------------- JVM Time Zone : 中欧时间 Test CURRENT_DATE() : 2018-09-18 Test CURRENT_TIME() : 03:56:02 Test CURRENT_TIMESTAMP() : 2018-09-18 04:56:02.0
能够看到结果是基本符合文档里的说明的,可是要注意,在Europe/Paris
时区,CURRENT_TIME()
和CURRENT_TIMESTAMP()
的时间部分相差一小时。
看上去CURRENT_TIMESTAMP()
返回的是UTC DST offset结果,而CURRENT_TIME()
返回的是UTC offset结果,关于这个我登记了Bug #92453。
关于Europe/Paris
的DST信息能够在这里找到Wiki - List of tz database time zones。
-- 查询系统时区和session时区 SELECT @@global.time_zone, @@session.time_zone; -- 设置session时区 SET time_zone = 'Asia/Shanghai';
详见:MySQL Server Time Zone Support
你能够在docker启动的时候设定MySQL容器的时区,好比这样-e TZ=Asia/Shanghai
。
这个方法有问题,会出现时间错乱,workaround是root用户链接到MySQL,而后执行SET GLOBAL time_zone = 'Asia/Shanghai';
。
这样客户端链接MySQL时,查询的时间的时区都是Asia/Shanghai
了。