南大通用GBase 8c MySQL迁移场景下的时区设置陷阱与解决方案 介绍

一、问题背景

将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 的时区配置规范
• 测试验证：  在适配时必须验证时区设置的正确性