Clickhouse跨服务器数据迁移时区异常与过滤范围偏差问题

一、为何时区设置显示正确但now()返回UTC时间？ #

• ClickHouse的timezone()函数返回的是当前会话的时区配置，但你使用的DBeaver可能在连接时强制覆盖了会话时区为UTC，或者工具自身的显示时区设为UTC，导致now()的输出被转换成UTC显示，而非服务器配置的Europe/Moscow时区。
• 另外，DateTime64类型本质是存储UTC时间戳，显示时会根据会话时区转换。如果实际会话时区是UTC（哪怕timezone()显示Europe/Moscow，可能是工具或连接参数的显示bug），now()自然会输出UTC时间。
• 验证方法：执行SELECT now(), toDateTime64(now(), 3, 'Europe/Moscow')，如果后者显示正确的莫斯科时间，说明会话时区确实是UTC，timezone()的返回结果不准确。

二、为何过滤条件会被转换为其他值？ #

• 当使用remote()函数跨服务器查询时，过滤条件中的字符串时间（如'2022-09-01 00:00:00'）会被当前会话时区解析为UTC时间戳，再与服务器A上_timestamp列存储的UTC时间戳对比。
• 你的情况是：查询目标表时DBeaver用UTC显示时间，实际数据的时间戳对应的是你期望的莫斯科时间范围，只是被转换成UTC格式展示——比如2022-08-31 21:00:00（UTC）刚好对应莫斯科时间的2022-09-01 00:00:00，这说明过滤逻辑本身是正确的，只是显示时区导致了误解。
• 若会话时区与服务器时区不一致，也会出现过滤条件被错误解析的情况：比如会话时区是UTC，你写的莫斯科时间字符串会被当成UTC时间解析，导致过滤范围偏差3小时。

解决方案 #

• 调整DBeaver连接时区：在ClickHouse连接的属性设置中，找到时区选项，手动设置为Europe/Moscow，覆盖默认的UTC设置。
• 显式指定过滤条件的时区：将过滤条件改为_timestamp >= toDateTime64('2022-09-01 00:00:00', 3, 'Europe/Moscow')，确保字符串时间按莫斯科时区解析，不受会话时区影响。
• 迁移时强制时区转换：在SELECT语句中对时间列显式转换时区，比如toDateTime64(_timestamp, 3, 'Europe/Moscow') AS _timestamp，保证目标表存储的时间戳对应正确的时区逻辑。

内容的提问来源于stack exchange，提问作者Alexandr