TiCDC时区问题

[CAI001 (Ti D Ber Mhmp8yq Z)]

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

[TiDBer_wk (Ti D Ber Os7emy Bg)]

是的。 Jenkins

[CAI001 (Ti D Ber Mhmp8yq Z)]

有什么解决方案吗？

[TiDBer_wk (Ti D Ber Os7emy Bg)]

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

[TiDBer_wk (Ti D Ber Os7emy Bg)]

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

[CAI001 (Ti D Ber Mhmp8yq Z)]

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

[TiDBer_wk (Ti D Ber Os7emy Bg)]

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

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

[TiDBer_wk (Ti D Ber Os7emy Bg)]

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

[CAI001 (Ti D Ber Mhmp8yq Z)]

我是不是可以这样理解，debezium协议的数据传输，timestamp类型转换后会是UTC时区的值；datetime会默认是UTC时间，直接转为时间戳。

这样就能解释我的现象了，timestamp转换为了UTC时间（少了8小时）。datetime转换为了时间戳，但是我通过工具转换的时候直接将时间戳按照东八区的时间格式转换了，反映出来的现象多了8小时。

[我是火炎焱燚 (Ti D Ber 9 Dh P An J6)]

TiDB 中 timestamp 和 datetime 类型的时区处理逻辑不同，结合 TiCDC 同步到 Kafka 时的时间偏差问题，核心原因通常与 TiCDC 对两种时间类型的序列化逻辑 及 时区配置生效机制 有关。

[独善其身 (Ti D Ber Bi Rqfz5 K)]

时区用utc再减去8试试啊,或者看看能不能把timestamp类型改为datetime之后再走cdc

[Augenstern]

最优方案：修改 TiCDC 同步任务配置，通过 time-zone=Asia/Shanghai、disable-datetime-zone-conversion=true、enable-timestamp-local-time=true 三个参数统一时区转换规则

[Kongdom]

@TiDBer_wk

debezium connect 的输出也是 “2025-07-13T07:54:31Z”，这里实际存储是 UTC 时间 “2025-07-13T07:54:31Z”，

那就是输出和实际存储是一致的吧。