原文链接：www.gbase.cn/community/p…
更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。
一、问题背景
将MySQL迁移到GBase 8c数据库时，遇到了一个令人困惑的时区问题：当按照MySQL使用方式来设置时区时，时间显示出现了完全相反的结果。
二、问题现象
2.1 MySQL时区的设置方法
在MySQL中，设置时区有两种方式：一种用数字方式，一种直接用时区名字，如下：
Mysql> SET time_zone = \'+08:00\';
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like \'%zone%\';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | |
| time_zone | +08:00 |
+------------------+--------+
2 rows in set, 1 warning (0.00 sec)
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2025-10-19 22:13:10 |
+---------------------+
1 row in set (0.00 sec)
或者
SET time_zone = \'Asia/Shanghai\';
2.2 GBase 8c按照MySQL类似方法设置
-- 在 GBase 8c 中
swjtdb=# show timezone;
TimeZone
----------
PRC
(1 row)
swjtdb=# select now();
now()
---------------------
2025-10-19 22:23:18
(1 row)
swjtdb=# SET timezone = \'+08:00\';
SET
swjtdb=# show timezone;
TimeZone
----------
+08:00
(1 row)
swjtdb=# select now();
now()
---------------------
2025-10-19 06:23:39.868943-08 <<<<<<该时间与实际差了16个小时，可以看到其实是-8
(1 row)
时间显示比预期少了 16 小时，这显然不是简单的时区设置错误。
使用另外一种方式时区进行设置看看：
swjtdb=# SET timezone = \'Asia/Shanghai\';
SET
swjtdb=# show timezone;
TimeZone
---------------
Asia/Shanghai
(1 row)
swjtdb=# select now();
now()
---------------------
2025-10-19 22:25:39.900286+08
(1 row)
这个时区设置是正确的，时间正常。
三、问题诊断过程
3.1初步排查
首先确认时区设置确实生效：
show timezone;
3.2深度测试
通过系统性的测试来定位问题根源：
-- 测试时区转换行为
WITH test_times AS (
SELECT \'2025-10-19 12:00:00\'::timestamptz as test_ts
)
SELECT
test_ts,
test_ts AT TIME ZONE \'UTC\' as as_utc,
test_ts AT TIME ZONE \'+08:00\' as as_beijing,
test_ts AT TIME ZONE \'-08:00\' as as_negative
FROM test_times;
测试结果：
test_ts | as_utc | as_beijing | as_negative
------------------------+---------------------+---------------------+---------------------
2025-10-19 12:00:00+08 | 2025-10-19 04:00:00 | 2025-10-18 20:00:00 | 2025-10-19 12:00:00
(1 row)
3.3关键发现
进一步测试确认了问题的本质：
SELECT
\'2025-10-19 12:00:00\'::timestamptz as base_time,
(\'2025-10-19 12:00:00\'::timestamptz AT TIME ZONE \'+08:00\') as plus_eight,
(\'2025-10-19 12:00:00\'::timestamptz AT TIME ZONE \'-08:00\') as minus_eight;
结果：
base_time | plus_eight | minus_eight
------------------------+---------------------+---------------------
2025-10-19 12:00:00+08 | 2025-10-18 20:00:00 | 2025-10-19 12:00:00
base_time: 2025-10-19 12:00:00+08 -- 时间正确
plus_eight: 2025-10-18 20:00:00 -- 时间不对
minus_eight: 2025-10-19 20:00:00 -- 时间正确
四、问题根源
时区偏移量符号反转：在 GBase 8c 中，时区偏移量的符号处理方式：
- +08:00 被解释为 UTC-8
-
- 08:00 被解释为 UTC+8
符号完全相反！
五、解决方案
1、方案1：使用简化数字语法（推荐）
在测试过程中，我们发现 GBase 8c 支持简化的数字时区语法：
-- 这些语法正常工作
SET timezone = \'8\'; -- 最简洁
SET timezone = \'08\'; -- 两位数
这种设置方式，也许有人问题如果MySQL那边是SET time_zone = \’+01:30\’ 这种设置，GBase 8c该如何用这种简化的数据时区设置呢？答案如下：
SET timezone = \'1.5\';
是不是比较难以理解？当然如果你要比较方便理解，可以用 SET timezone = \’-01:30\’; 来到达同样的效果，只不过看起来有点相反的意思。
-- 验证
SHOW TimeZone; -- 返回 08:00:00
SELECT now(); -- 正确显示 UTC+8 时间
2、方案2：使用命名时区（标准做法）
-- 使用命名时区完全避免数字偏移量问题
SET timezone = \'Asia/Shanghai\';
SET timezone = \'PRC\';
-- 验证可用时区
SELECT name, utc_offset
FROM pg_timezone_names
WHERE utc_offset = \'08:00:00\'::interval;
六、最佳实践总结
1、推荐的时区设置方式
- 首选命名时区：SET timezone = \’Asia/Shanghai\’;
- 次选简化数字语法：SET timezone = \’8\’;
- 避免偏移量：与ISO偏移量相反，东八区要设置成 \’-08:00\’ ，而不是\’+08:00\’
2、对应用开发的影响
- 可移植性问题：在 GBase 8c和MySQL 之间迁移时需要修改时区设置语法
- 配置标准化：需建立针对 GBase 8c 的时区配置规范
- 测试验证： 在适配时必须验证时区设置的正确性
原文链接：www.gbase.cn/community/p…
更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。
