CONVERT_TZ()需显式指定源时区，否则误转；AT TIME ZONE是后缀操作符，语义易混淆；JOIN中时区转换须提前物化或移至外层，避免索引失效；夏令时边界小时可能导致静默错配。
MySQL中用CONVERT_TZ()做跨时区JOIN，必须显式指定源时区和目标时区
CONVERT_TZ() 不会自动推断时间字段的原始时区，它只按你给的三个参数机械转换：时间值、源时区字符串、目标时区字符串。如果表A存的是 '2024-05-20 14:30:00'（实际是上海时间），但没记录时区信息，直接写 CONVERT_TZ(created_at, '+00:00', '+08:00') 就会错——它把原值当成UTC来转，结果多加8小时。
常见错误现象是关联结果为空或错位半天。正确做法是确认数据物理存储时区，再填对第二个参数。比如日志表明确用 Asia/Shanghai 写入，JOIN时就得写：
CONVERT_TZ(t1.event_time, 'Asia/Shanghai', 'America/New_York')注意：时区名必须是系统支持的（查
SELECT * FROM mysql.time_zone_name），不能用 GMT+8 这类简写（MySQL不认）。
PostgreSQL里用AT TIME ZONE做JOIN，时区参数位置和语义容易反直觉
AT TIME ZONE 是后缀操作符，不是函数调用。写法是 event_time AT TIME ZONE 'UTC'，意思是“把当前字段值当作本地时间，解释成UTC时间戳”。如果字段本身是 TIMESTAMP WITHOUT TIME ZONE 类型（最常见），这个操作才生效；如果是 TIMESTAMP WITH TIME ZONE，它反而会做一次时区转换再转回本地表示。
使用场景上，跨时区JOIN通常两边都要归一化到同一时区，比如：
ON (t1.created_at AT TIME ZONE 'Asia/Shanghai') = (t2.occurred_at AT TIME ZONE 'America/Los_Angeles')这行代码实际效果是：先把两个无时区时间分别按各自原始时区解释，再统一转成UTC时间点比较。关键点在于——你得确保字段值和AT TIME ZONE后面的字符串匹配真实业务时区，否则逻辑就偏了。
JOIN性能受时区转换影响大，别在ON条件里反复调用转换函数
所有主流数据库都会让带函数的JOIN条件无法使用索引。比如写 ON CONVERT_TZ(t1.ts, 'Asia/Shanghai', 'UTC') = t2.utc_ts，哪怕t1.ts有索引，也用不上。
解决办法只有两个：
- 提前物化转换结果：加一个生成列（MySQL 5.7+）或表达式索引（PostgreSQL），例如
ALTER TABLE events ADD COLUMN ts_utc TIMESTAMP GENERATED ALWAYS AS (CONVERT_TZ(ts, 'Asia/Shanghai', '+00:00')) STORED，然后对这个列建索引 - 把转换移到JOIN外层：先用子查询或CTE把一边的时间转好，再JOIN，例如
WITH t1_utc AS (SELECT id, CONVERT_TZ(event_time, 'Asia/Shanghai', 'UTC') AS event_utc FROM logs)，后续JOIN用t1_utc.event_utc
另外注意：时区缩写如 CST 在不同系统含义不同（可能是China Standard Time，也可能是Central Standard Time），务必用全称或固定偏移量。
时区夏令时切换会导致JOIN结果非幂等，尤其在3月/11月边界小时
CONVERT_TZ() 和 AT TIME ZONE 都会遵守系统时区规则库，遇到夏令时跳变（比如美国3月第二个周日凌晨2点变3点），同一个本地时间可能对应两个UTC时间（秋收重叠），或者根本不存在（春分跳过）。这时候JOIN可能漏掉一行，或某行被重复关联。
最容易被忽略的地方是：这种问题不会报错，也不会告警，只在特定日期、特定小时静默出错。如果你的业务依赖精确到小时的跨时区统计（比如每小时订单归因），建议避开 2:00–3:00 这类模糊窗口，改用UTC时间做主键或分区依据。毕竟，时区是给人看的，时间线才是机器算的。
