dm同步TIMESTAMP类型的字段时比原表少12个小时

[tuyi锅子]

【 TiDB 使用环境】测试环境
【 TiDB 版本】6.1.0
【dm版本】5.4.0
【遇到的问题】
create_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP这种字段通过dm同步到tidb发现比原表的时间少了12个小时，从binglog中找出TIMESTAMP 字段的值直接通过FROM_UNIXTIME()函数解析后，时间是一致的，并不会相差12小时。
时区：
有大佬碰到过同样的问题吗？

[db_user]

你好能发下上下游的time_zone配置么
然后binlog的配置是什么样的，row格式么

是全量阶段出现的问题还是增量阶段的，如果是增量阶段的能用mysqlbinlog解析一小段么，看一下真实同步到下游是什么样的

[tuyi锅子]

上游MySQL time_zone：
下游tidb time_zone：
binlog是row格式的
增量阶段出现的，全量的是正常的
binlog：

这是测试的数据，框框中的是有问题的字段，如果哪这个值直接到MySQL和tidb上解析成时间是一致的

[tuyi锅子]

不知道为啥tidb的system_time_zone是America/New_York，
timedatectl命令的结果：

[tuyi锅子]

tidb数据：

MySQL数据：

create_time和update_time相差12个小时

[db_user]

我试下看我这里能不能复现，正常来说time_zone不是system的话应该就没有问题，不会走system_time_zone,system_time_zone是你服务器设置的时区

另外麻烦看下binlog这条数据的上面有没有类似set 设置时区或者其他的信息

[tuyi锅子]

binlog有设置时区的，但是和sql语句的值是一样的

[forever]

检查下dm服务器的时区是什么呢，然后把你在binglog里查到timestamp去dm服务器上解析下看是什么时间，怀疑你dm服务器的时间导致的时间差12小时

[tuyi锅子]

dm时区也检查过了是正常的，dm配置的时候手动指定时区解决了这个问题。

[tuyi锅子]

dm配置的时候手动指定时区解决了这个问题。dm的版本是5.4.0，生产环境的dm版本是6.1.0没有发现这个问题

[db_user]

看起来就是时区的问题，但是上下游时区正常不应该这样，我也拿我的测试环境试下，有可能是个bug

[forever]

你看下生产的跟这个的操作系统时区是一样的吗

[Hacker007]

如果binlog的日志格式是 Statement会出现你这问题