TiCDC时区问题

CAI001 · 2025 年7 月 15 日 06:11

是和我的情况一样，timestamp 少了8小时吗？

TiDBer_wk · 2025 年7 月 15 日 06:11

CAI001 · 2025 年7 月 15 日 06:37

有什么解决方案吗？

TiDBer_wk · 2025 年7 月 15 日 07:37

应该是个 bug，需要查下为什么会出现, 记了一个 issue CDC: incorrect timestamp value in debezium protocol · Issue #12243 · pingcap/tiflow · GitHub

TiDBer_wk · 2025 年7 月 16 日 02:51

我重新进行测试后发现结果是没问题的，你在设置 GLOBAL time_zone 和 create table 是在一个 session 下做的吗？https://github.com/pingcap/tiflow/pull/12242/files#diff-13625772214eb554539e3cfa2fdc84cd9ad74b64e03c95dc668217c8e44b2b39R53-R56

CAI001 · 2025 年7 月 16 日 02:53

不是，GLOBAL time_zone 在集群刚起来的时候就设置了

TiDBer_wk · 2025 年7 月 16 日 08:29

从测试看，debezium connect 的输出也是 “2025-07-13T07:54:31Z”，这里实际存储是 UTC 时间 “2025-07-13T07:54:31Z”，按照文档来说，读取时应该是根据 database’s time zone 转为对应的时区值的，你们之前有使用过其他 debezium 协议的工具吗，他们的输出是什么呢？

SET GLOBAL time_zone = ‘UTC’;
输出为 “2025-07-13T15:54:31Z”，TiCDC 和 debezium/connect 输出一致
SET GLOBAL time_zone = ‘Asia/Shanghai’;
输出为 “2025-07-13T07:54:31Z”，TiCDC 和 debezium/connect 输出一致

TiDBer_wk · 2025 年7 月 17 日 03:11

这个结果是符合预期的。无论如何调整时区值，DATETIME 数据类型的值不会受到影响。TIMESTAMP 数据类型的显示值会根据时区的变化而变化。