数据库时区

‘壹’ mysql 的 timestamp 会存在时区问题，java 技术专家方向

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

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

接着，修改当前会话的时区为+9:00，即日本的东 9 区，再次查看数据。

定义为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 时间缀，结果为 1582416000。使用 mysql 的from_unixtime()函数，将 unix 时间缀转换为 mysql 时间类型来插入数据。查询出来的时间，也是东 9 区的 9 点，时间正确。

网上说 timestamp 类型存在时区问题，多数源于应用端插入数据，然后到数据库中查看，结果发现时间不一致。尝试在 Java 中重现这个问题。

将数据库的时区设置为+09:00时区，即日本的东 9 区。在 Java 中定义 Entity 的时间属性为 Date 类型。插入数据时，应用的时区为东 8 区。查询数据时，time_stamp 字段时间是 9 点，时间正确。使用/queryAll接口查询数据，timeStamp属性是毫秒级的时间缀，秒级也是东 8 区的 8 点，时间正确。

在 mysql 时区修改回+8:00，并重启 Java 应用。查询数据，timeStamp属性还是毫秒级的时间缀，时间没有变化，正确。

网上说 timestamp 存在时区问题，原因在于 jdbc 的serverTimezone 配置。将数据库时区修改回+9:00时区，故意将 jdbc 的 url 上的 serverTimezone 配置为与数据库不一致的 GMT+8 时区，重启 Java 应用。插入数据时，时间显示为 8 点，与预期的 9 点不符。

使用/queryAll接口查询数据，timeStamp是毫秒级的时间缀，秒级也是东 8 区的 8 点，查询结果正确。调试 mysql 的 jdbc 驱动代码，发现 mysql 驱动在发送 sql 前，会将 jdbc 中的 Date 对象参数，根据 serverTimeZone 配置的时区转化为日期字符串后，再发送 sql 请求给 mysql server。

mysql 驱动在发送 sql 前，会将 jdbc 中的 Date 对象参数转化为字符串，然后发送给 mysql server，mysql server 返回查询结果后，结果中的日期值也是字符串，mysql 驱动会根据 serverTimeZone 配置的时区，将日期字符串转化为 Date 对象。

当 serverTimeZone 与数据库实际时区不一致时，会发生时区转换错误，导致时间偏差。正确的做法是将 serverTimezone 与 mysql 时区保持一致，避免时区转换错误。

将 serverTimezone 与 mysql 时区保持一致，可以避免时区问题。当没有配置 serverTimezone 时，mysql 驱动会自动读取 mysql server 中配置的时区，需要注意默认时区 SYSTEM 的混乱问题。正确的做法是确保 serverTimezone 与数据库时区一致，或在无法修改数据库时区时，明确配置 serverTimezone。

‘贰’ 一篇永久摆脱Mysql时区错误问题，idea数据库可视化插件配置

在项目开发过程中，遇到了一个与MySQL时区相关的棘手问题，针对此问题，我将在本文中详细记录解决步骤，以期对遇到同样问题的开发者有所帮助。

问题起因在于使用Mysql 8.0.15时，数据库的时区设置引发的报错。尝试使用IDEA中的数据库可视化插件进行连接时，报错信息提示了时区不匹配。

首先，我们从源头分析：检查数据库本身的默认时区设置，以及IDEA插件连接时的时区设置。考虑到可能是系统默认时区与插件设置不一致，我尝试在命令行中修改MySQL服务的时区，临时将它设置为'+8:00'，但这只是临时解决方案，重启服务后会恢复原设置。

为实现永久性解决，我找到了更深层次的配置方法：修改MySQL的my.ini配置文件，在[mysqld]部分添加'default-time-zone=+08:00'，重启服务后即可生效。但请注意，配置项要在正确的区块中添加，以避免未知变量错误。

然而，即使这样，我在IDEA插件中仍收到错误。这时，我意识到问题可能出在插件的连接配置上。于是，我调整了插件的时区设置，将其设置为'+8:00'，最终成功解决了这个问题。

虽然这个过程稍微繁琐，但问题本身并不复杂。如果你也遇到了类似问题，按照这些步骤操作应该能顺利解决。感谢阅读，如果有帮助，请分享给更多需要的人。

‘叁’ mysql数据库,datetime类型的数据如何指定展示的时区

MySQL的DATETIME类型保存的是日期与时间，以本地时区表示。若需调整显示时区，可借助CONVERT_TZ()函数实现。假设你有一列datetime，存储的为UTC时间，想要转换为美国东部时间（EST），可通过下述查询：

该查询中，第一个参数为待转换时间值，第二个参数为输入时区，第三个参数为输出时区。以此例，查询将datetime_column中读取的UTC时间值转化为EST时间。

使用CONVERT_TZ()函数转换时区的步骤如下：选定时间值，输入原时区，输出时区。例如，将UTC时间转换为EST时间的查询代码如上所述。通过这个方法，你可以轻松调整MySQL中DATETIME类型数据的时区显示。

若数据库中数据为其他时区，只需替换输入与输出时区即可实现相应转换。CONVERT_TZ()函数提供灵活的时区调整功能，帮助你适应不同的数据展示需求。

通过以上步骤和示例，你可以有效地使用MySQL的CONVERT_TZ()函数调整DATETIME类型数据的时区显示。这为跨时区数据操作提供了便捷，确保了数据展示的一致性与准确性。

‘肆’ 一文解决MySQL时区相关问题

前言：
在使用MySQL的过程中，时区相关问题可能会导致时间显示错误、时区设置不当等问题。本文将从数据库参数入手，逐步介绍时区相关内容，帮助解决这些常见问题。
log_timestamps参数：
该参数用于控制错误日志、慢查询日志、通用日志中的时间显示，但不直接影响时区。默认使用UTC时区，导致日志记录的时间比北京时间慢8小时。修改为SYSTEM可以使用系统时区，便于查看日志。
time_zone参数：
该参数用于设置每个连接会话的时区，可动态修改。默认为SYSTEM，继承自当前系统时区。时区设置主要影响时间值的显示和存储，包括now()、curtime()等函数的显示值以及TIMESTAMP类型值的存储。
时区常见问题及解决方法：
1. MySQL内部时间非北京时间
检查系统时间及时区是否正确，修改time_zone为'+8:00'。
2. Java程序与数据库时间相差8小时
检查两边时区，统一采用北京时间。修改jdbc连接串中的serverTimezone为Asia/Shanghai，并将time_zone设置为'+8:00'。
3. 程序与数据库时间相差13小时或14小时
明确指定MySQL数据库时区，避免使用引发误解的CST，将time_zone改为'+8:00'，同时调整jdbc连接串的serverTimezone为Asia/Shanghai。
如何避免时区问题：
建议将time_zone修改为'+8:00'，尤其在频繁查询TIMESTAMP字段时，避免系统时区转换带来的性能限制。
总结：本文深入探讨了MySQL时区相关问题及解决方法，希望对您有所帮助。了解并正确设置时区参数，可以有效避免时间显示错误和时区不一致等问题。欢迎留言讨论其他时区相关问题。

‘伍’ 通用时区：你应该知道的数据库时区知识

摘要：本文深入探讨了通用时区数据库的组织规则，时区和夏令时的维护机制，以及GaussDB(DWS)如何利用IANA维护的时区数据。

1. 背景介绍

通用时区数据库组织全球各地的时区信息，包括时区和夏令时的变更历史。此数据库由David Olson创建，Paul Eggert编辑和维护，称为Olson数据库或IANA时区数据库。其独特之处在于以“区域/位置”格式命名每个时区，如“America/New_York”。数据库每年更新，以反映各国政府对时区边界的调整和夏令时规则的变化。

2. 通用时区数据库源码和维护方法

时区数据库包含两大组成部分：文本文件和解析代码。文本文件记录时区定义，解析代码用于将这些定义转换为二进制时区文件。数据库由IANA维护，提供三种访问方式。zic工具用于将原始文本文件解析为二进制文件，以供软件产品使用。

3. 时区数据库的使用

操作系统和数据库使用时区文件，如/etc/localtime，存储在特定目录下。这些文件遵循IANA定义的格式，包含标准时间和夏令时信息，以及时间变更的历史记录。使用时区文件可自动转换时间，广泛应用于各种系统。

4. GaussDB(DWS)中的时区数据应用

GaussDB(DWS)根据IANA语法定义了Asia/Beijing时区，与PRC时区一致。用户可通过查看具体定义文件了解时区详细信息。GaussDB(DWS)支持时区数据，满足全球用户的需求。

5. 总结

GaussDB(DWS)作为高性能分析型数据库，支持符合工业界标准的时区数据。了解时区数据库的原理和维护有助于正确使用时区功能。关注官方公众号获取更多关于GaussDB(DWS)的技术资讯。