数据库时区那些事儿 - MySQL的时区处理

原文地址php

当JVM时区和数据库时区不一致的时候,会发生什么?这个问题也许你历来没有注意过,可是当把Java程序容器化的时候,问题就浮现出来了,由于目前几乎全部的Docker Image的时区都是UTC。本文探究了MySQL及其JDBC驱动对于时区的处理方式,并尝试给出最佳实践。html

先给总结

  • DATETIME类型不支持时区转换。
  • 对于TIMESTAMP类型,MySQL会正确的根据connection时区(对于JDBC来讲就是JVM时区)/服务端时区作转换。java

    • JDBC程序不须要特别注意什么事情。只要保证JVM时区和用户所在时区保持一致便可。
  • 不要在服务器端作日期时间的字符串格式化(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 Typesmysql

MySQL converts TIMESTAMP 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 as DATETIME.)
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 a TIMESTAMP 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

  1. 查询TIMESTAMP类型所返回的值,会根据connection的时区(对于JDBC来讲就是JVM时区)作转换
  2. 在MySQL中只有TIMESTAMP类型会作时区转换

为了验证这个结论,我写了一段程序来实验,这个程序作了三件事情:github

  1. 使用Asia/Shanghai时区构造一个日期java.util.Date2018-09-14 10:00:00,而后插入到数据库里(表:test,列:timestamp类型)
  2. 使用Asia/Shanghai时区把这个值再查出来,看看结果。
  3. 使用Asia/Shanghai时区,得到这个字段的格式化字符串(使用DATE_FORMAT()函数)。
  4. 使用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安全

The CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE(), and FROM_UNIXTIME() functions return values
in the connection's current time zone, which is available as the value of the time_zone system variable.

并且根据文档所讲,它们返回的结果匹配当前链接所设定的时区。

为了验证这个结论,一样写了一段程序,分别使用Asia/ShanghaiEurope/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

在MySQL客户端操做时区

-- 查询系统时区和session时区
SELECT @@global.time_zone, @@session.time_zone;

-- 设置session时区
SET time_zone = 'Asia/Shanghai';

详见:MySQL Server Time Zone Support

Docker启动时设定时区

你能够在docker启动的时候设定MySQL容器的时区,好比这样-e TZ=Asia/Shanghai

这个方法有问题,会出现时间错乱,workaround是root用户链接到MySQL,而后执行SET GLOBAL time_zone = 'Asia/Shanghai';

这样客户端链接MySQL时,查询的时间的时区都是Asia/Shanghai了。

参考资料

相关代码

https://github.com/chanjarste...

相关文章
相关标签/搜索