MySQL 是否应该将其时区设置为 UTC？

如何解决MySQL 是否应该将其时区设置为 UTC？

只要您为当前时区设置了正确的时间，知道您存储的日期时间列的时区，并且知道夏令时的问题，服务器上的时区似乎并不重要。

另一方面，如果您可以控制所使用服务器的时区，那么您可以在内部将所有内容设置为 UTC，而不必担心时区和 DST，至少在存储内部时间方面是这样。

以下是我收集的一些关于如何使用时区作为我自己和其他人的备忘单形式的笔记，这可能会影响人们将为他/她的服务器选择哪个时区以及他/她将如何存储日期和时间。

MysqL 时区备忘单

笔记：

1. 更改时区 ，但会从时间戳列中选择不同的日期时间

2. UTC 有闰秒，这些看起来像 ‘2012-06-30 23:59:60’ 并且可以随机添加，由于地球自转速度减慢，提前 6 个月通知

3. GMT 混淆了秒数，这就是发明 UTC 的原因。

4. 由于夏令时，不同的区域时区可能会产生相同的日期时间值

5. 由于限制，时间戳列仅支持日期 1970-01-01 00:00:01 到 2038-01-19 03:14:07 UTC 。

6. MySQL 时间戳列在内部存储为UTC，但在选择日期时，MysqL 会自动将其转换为当前会话时区。

在时间戳中存储日期时，MysqL 将假定日期在当前会话时区中，并将其转换为 UTC 进行存储。

1. MysqL 可以在日期时间列中存储部分日期，这些看起来像“2013-00-00 04:00:00”

2. 如果您将日期时间列设置为 NULL，MysqL 将存储“0000-00-00 00:00:00”，除非您在创建该列时专门设置该列以允许为空。

选择 UTC 格式的时间戳列

无论当前 MysqL 会话在哪个时区：

SELECT 
CONVERT_TZ(`timestamp_field`, @@session.time_zone, '+00:00') AS `utc_datetime` 
FROM `table_name`

您还可以将服务器或全局或当前会话时区设置为 UTC，然后选择时间戳，如下所示：

SELECT `timestamp_field` FROM `table_name`

要选择 UTC 中的当前日期时间：

SELECT UTC_TIMESTAMP();
SELECT UTC_TIMESTAMP;
SELECT CONVERT_TZ(Now(), @@session.time_zone, '+00:00');

示例结果：2015-03-24 17:02:41

在会话时区中选择当前日期时间

SELECT Now();
SELECT CURRENT_TIMESTAMP;
SELECT CURRENT_TIMESTAMP();

选择服务器启动时设置的时区

SELECT @@system_time_zone;

返回莫斯科时间的“MSK”或“+04:00”，例如，存在（或曾经）一个 MysqL 错误，如果设置为数字偏移量，它将不会调整夏令时

获取当前时区

SELECT TIMEDIFF(Now(), UTC_TIMESTAMP);

如果您的时区是 +2:00，它将返回 02:00:00。

获取当前 UNIX 时间戳（以秒为单位）：

SELECT UNIX_TIMESTAMP(Now());
SELECT UNIX_TIMESTAMP();

获取时间戳列作为 UNIX 时间戳

SELECT UNIX_TIMESTAMP(`timestamp`) FROM `table_name`

获取 UTC 日期时间列作为 UNIX 时间戳

SELECT UNIX_TIMESTAMP(CONVERT_TZ(`utc_datetime`, '+00:00', @@session.time_zone)) FROM `table_name`

从正 UNIX 时间戳整数获取当前时区日期时间

SELECT FROM_UNIXTIME(`unix_timestamp_int`) FROM `table_name`

从 UNIX 时间戳获取 UTC 日期时间

SELECT CONVERT_TZ(FROM_UNIXTIME(`unix_timestamp_int`), @@session.time_zone, '+00:00') 
FROM `table_name`

从负 UNIX 时间戳整数中获取当前时区日期时间

SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)

在 MysqL 中有 3 个地方可以设置时区：

注意：时区可以设置为 2 种格式：

1. 与 UTC 的偏移量：“+00:00”、“+10:00”或“-6:00”
2. 作为命名时区：“欧洲/赫尔辛基”、“美国/东部”或“MET”

只有在 MysqL 数据库中的时区信息表已创建并填充后，才能使用命名时区。

在文件“my.cnf”中

default_time_zone='+00:00'

或者

timezone='UTC'

@@global.time_zone 变量

查看它们设置为什么值

SELECT @@global.time_zone;

要为其设置值，请使用以下任一：

SET GLOBAL time_zone = '+8:00';
SET GLOBAL time_zone = 'Europe/Helsinki';
SET @@global.time_zone='+00:00';

@@session.time_zone 变量

SELECT @@session.time_zone;

要设置它，请使用以下任一：

SET time_zone = 'Europe/Helsinki';
SET time_zone = "+00:00";
SET @@session.time_zone = "+00:00";

“@@global.time_zone 变量”和“@@session.time_zone 变量”都可能返回“SYstem”，这意味着它们使用“my.cnf”中设置的时区。

http://dev.mysql.com/doc/refman/5.1/en/time-zone-support。 html

注意：你不能这样做，因为它会返回 NULL：

SELECT 
CONVERT_TZ(`timestamp_field`, TIMEDIFF(Now(), UTC_TIMESTAMP), '+00:00') AS `utc_datetime` 
FROM `table_name`

设置MysqL时区表

为了CONVERT_TZ工作，您需要填充时区表

SELECT * FROM MysqL.`time_zone` ;
SELECT * FROM MysqL.`time_zone_leap_second` ;
SELECT * FROM MysqL.`time_zone_name` ;
SELECT * FROM MysqL.`time_zone_transition` ;
SELECT * FROM MysqL.`time_zone_transition_type` ;

如果它们是空的，则通过运行此命令来填充它们

MysqL_tzinfo_to_sql /usr/share/zoneinfo | MysqL -u root -p MysqL

如果此命令给出错误“ data too long for column ‘abbreviation’ at row 1 ”，则可能是由于在时区缩写末尾附加了 NULL 字符

修复是运行这个

MysqL_tzinfo_to_sql /usr/share/zoneinfo | MysqL -u root -p MysqL
(if the above gives error "data too long for column 'abbreviation' at row 1")
MysqL_tzinfo_to_sql /usr/share/zoneinfo > /tmp/zut.sql

echo "SET SESSION sql_mode = '';" > /tmp/MysqL_tzinfo_to.sql
cat /tmp/zut.sql >> /tmp/MysqL_tzinfo_to.sql

MysqL --defaults-file=/etc/MysqL/my.cnf --user=verifiedscratch -p MysqL < /tmp/MysqL_tzinfo_to.sql

（确保您的服务器 dst 规则是最新的zdump -v Europe/Moscow | grep 2011https://chrisjean.com/updating-daylight-saving-time-on- linux/）

查看每个时区的完整 DST（夏令时）转换历史

SELECT 
tzn.Name AS tz_name,
tztt.Abbreviation AS tz_abbr,
tztt.Is_DST AS is_dst,
tztt.`Offset` AS `offset`,
DATE_ADD('1970-01-01 00:00:00',INTERVAL tzt.Transition_time SECOND)  AS transition_date
FROM MysqL.`time_zone_transition` tzt
INNER JOIN MysqL.`time_zone_transition_type` tztt USING(Time_zone_id, Transition_type_id)
INNER JOIN MysqL.`time_zone_name` tzn USING(Time_zone_id)
-- WHERE tzn.Name LIKE 'Europe/Moscow' -- Moscow has weird DST changes
ORDER BY tzt.Transition_time ASC

CONVERT_TZ还根据上表中的规则和您使用的日期应用任何必要的 DST 更改。

根据文档，您为 time_zone 设置的值不会改变，例如，如果您将其设置为“+01:00”，那么 time_zone 将设置为与 UTC 的偏移量，它不遵循 DST，所以它将全年保持不变。

只有指定的时区会在夏令时更改时间。

像这样的缩写CET将始终是冬季时间和CEST夏季时间，而 +01:00 将始终是UTC时间 + 1 小时，两者都不会随 DST 改变。

system时区将是安装 MysqL 的主机的时区（除非 MysqL 无法确定它）

您可以在此处阅读有关使用 DST 的更多信息

传奇人物 Jon Skeet 何时不使用 UTC：https ://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a- silver-bullet/ （例如未来的预定活动代表一个时间，而不是一个瞬间）

解决方法

https://serverfault.com/questions/191331/should-servers-have-their-timezone-
set-to-gmt-utc的后续问题

MySQL 时区应该设置为 UTC 还是应该设置为与服务器或 PHP 设置相同的时区？（如果不是UTC）

优缺点都有什么？