timestampdiff(second, ...) 不能直接算跨时区精确秒数，因其不感知时区，仅对输入作本地时间数值差；需先用 convert_tz 统一转为 utc 再计算，否则结果不可靠。
为什么 TIMESTAMPDIFF(SECOND, ...) 不能直接算跨时区精确秒数
TIMESTAMPDIFF 函数本身不感知时区——它只把两个参数当作「本地时间值」做数值差，不会自动转换为统一时区再计算。如果你传入的是带时区的字符串（如 '2024-05-01 12:00:00+0800'）或 TIMESTAMP WITH TIME ZONE 类型（MySQL 实际不原生支持该类型），MySQL 会按当前会话时区隐式截断/转换，结果不可靠。
常见错误现象：TIMESTAMPDIFF(SECOND, '2024-01-01 00:00:00+0000', '2024-01-01 00:00:00+0800') 返回 0，而非预期的 -28800，因为 MySQL 忽略了 +0000 和 +0800 后缀，全当成本地时间解析。
- MySQL 版本 ≤ 8.0.19：无内置时区转换函数处理带偏移字符串
-
TIMESTAMPDIFF的单位仅影响最终数值缩放，不改变输入解释逻辑 - 若两个时间字段存的是
TIMESTAMP类型，它们在存储时已转为 UTC，但查询时又按 session time_zone 回显——容易误以为“自带时区”
正确做法：先用 CONVERT_TZ 统一到 UTC 再差值
必须把两个时间都转成同一时区（推荐 UTC）的 TIMESTAMP 值，再交给 TIMESTAMPDIFF。前提是你的输入能被 MySQL 识别为有效时间字面量，且时区名或偏移可用。
示例：计算北京时间（Asia/Shanghai）与纽约时间（America/New_York）同一天正午的秒数差：
SELECT TIMESTAMPDIFF(SECOND,
CONVERT_TZ('2024-05-01 12:00:00', 'Asia/Shanghai', '+00:00'),
CONVERT_TZ('2024-05-01 12:00:00', 'America/New_York', '+00:00')
) AS sec_diff;
返回结果是 14400（即 4 小时 = 14400 秒），符合夏令时下的实际偏移（UTC+8 vs UTC-4）。
-
CONVERT_TZ第二个参数必须是系统已加载的时区名（查mysql.time_zone_name表确认），不能直接写'+08:00'字符串（MySQL 5.7+ 支持部分偏移写法，但行为不稳定） - 若只有固定偏移（如
+0800），建议先用字符串处理提取偏移，再用DATE_ADD手动校正 -
CONVERT_TZ对非法时区名返回NULL，务必检查输入是否匹配系统时区表
处理带偏移字符串（如 '2024-05-01 12:00:00+0800'）的绕过方案
MySQL 原生不解析 ISO 8601 带偏移格式。你得手动剥离偏移、转成 UTC 时间戳再计算。
步骤简述：
- 用
SUBSTR和LOCATE提取偏移部分（如'+0800'） - 将主时间字符串转为
TIMESTAMP（默认按 session time_zone 解析） - 用
TIME_TO_SEC把偏移转为秒，再用DATE_SUB或DATE_ADD校正到 UTC
例如，对 '2024-05-01 12:00:00+0800'：
SELECT TIMESTAMPDIFF(SECOND,
DATE_SUB(STR_TO_DATE(LEFT('2024-05-01 12:00:00+0800', 19), '%Y-%m-%d %H:%i:%s'),
INTERVAL (CAST(SUBSTR('2024-05-01 12:00:00+0800', -4, 2) AS SIGNED) * 3600 +
CAST(SUBSTR('2024-05-01 12:00:00+0800', -2) AS SIGNED) * 60) SECOND),
DATE_SUB(STR_TO_DATE(LEFT('2024-05-01 12:00:00-0400', 19), '%Y-%m-%d %H:%i:%s'),
INTERVAL (CAST(SUBSTR('2024-05-01 12:00:00-0400', -4, 2) AS SIGNED) * 3600 +
CAST(SUBSTR('2024-05-01 12:00:00-0400', -2) AS SIGNED) * 60) SECOND)
) AS sec_diff;
这个写法丑但有效——核心是：别依赖 MySQL 自动解析偏移，自己拆、自己算、自己对齐到 UTC。
更稳妥的替代思路：在应用层处理
真要频繁算跨时区精确秒数，SQL 层不是最佳选择。数据库缺乏完整时区规则（如 DST 变更历史），且 CONVERT_TZ 依赖系统时区表完整性。
- Python/Java 等语言有成熟库（
pytz、java.time.ZonedDateTime）可精确处理任意时区和历史偏移 - 把原始时间 + 时区信息作为字符串传入应用，由代码解析后转为 Unix 时间戳再相减，结果更可靠
- 如果必须走 SQL，至少确保所有时间字段统一存为
UNIX_TIMESTAMP整数（秒级），避免任何字符串解析歧义
跨时区时间差的本质是「两个时刻在绝对时间轴上的距离」，而这个轴只能靠 UTC 锚定。任何跳过 UTC 对齐的计算，都可能在夏令时切换日出错——这点很容易被忽略，但后果是线上数据偏差数小时。
