触发器中直接用CONVERT_TZ()易出错：一是时区名（如'Asia/Shanghai'）未加载导致报错“Unknown or incorrect time zone”；二是依赖mysql.time_zone_name表，若为空则静默返回NULL或报错FUNCTION does not exist。
触发器里直接用 CONVERT_TZ() 会出什么问题？
MySQL 的 CONVERT_TZ() 看似是跨时区转换的“标准解”，但它在触发器中容易踩两个坑：一是时区名（如 'Asia/Shanghai'）必须在 MySQL 服务端已加载，而很多云数据库默认只加载 SYSTEM 和 +00:00；二是该函数依赖系统时区表（mysql.time_zone*），若未初始化或权限不足，执行时直接报错 ERROR 1426 (HY000): Function 'convert_tz' does not exist 或 Unknown or incorrect time zone。
实操建议：
- 先运行
SELECT CONVERT_TZ(NOW(), '+00:00', '+08:00');验证基础功能是否可用 - 检查时区表是否填充：
SELECT COUNT(*) FROM mysql.time_zone_name;，结果为 0 就得用mysql_tzinfo_to_sql导入（但多数生产环境无 shell 权限） - 若仅需固定偏移（如东八区），优先用
DATE_ADD()+INTERVAL替代，更稳定
INSERT 触发器中写入本地时间戳，为什么 NOW() 不可靠？
NOW() 返回的是 MySQL 服务器当前会话的系统时间，它受 time_zone 会话变量控制。如果应用连接池没统一设置时区（比如有的连的是 +00:00，有的连的是 +08:00），同一个触发器在不同连接下生成的时间就可能差 8 小时。
实操建议：
- 在触发器开头显式设置会话时区：
SET time_zone = '+08:00';，再调用NOW() - 更稳妥的做法是让应用层传入带时区的时间字符串（如
'2024-05-20T14:30:00+08:00'），触发器用STR_TO_DATE()解析后转为 UTC 存储 - 避免依赖
CURRENT_TIMESTAMP默认值——它的行为和列定义时的time_zone绑定，后期修改易引发不一致
UPDATE 触发器更新时间字段，如何避免时区转换叠加？
常见错误是：原字段存的是 UTC 时间，触发器里又用 CONVERT_TZ(old_value, '+00:00', '+08:00') 转一次，再存回同一字段，导致二次转换。尤其当触发器被多次触发（如级联更新），时间会越转越偏。
实操建议：
- 明确字段语义：是存 UTC 还是本地时间？推荐统一存 UTC，所有转换在应用层或查询层做
- 在 UPDATE 触发器中，只更新「最后修改时间」这类元数据字段，且始终用
UTC_TIMESTAMP()赋值，绕过时区干扰 - 若必须存本地时间，用
CONVERT_TZ(UTC_TIMESTAMP(), '+00:00', '+08:00')，而不是基于旧值转换
PostgreSQL 触发器怎么处理时区？CURRENT_TIMESTAMP 和 NOW() 有区别吗？
PostgreSQL 中 CURRENT_TIMESTAMP 和 NOW() 完全等价，都返回带时区的 timestamptz 值，内部以 UTC 存储，显示时按会话 timezone 设置格式化。这比 MySQL 更透明，但也带来一个隐藏问题：触发器里直接赋值 CURRENT_TIMESTAMP 到 timestamp without time zone 字段，会静默丢掉时区信息，变成本地时间字面量。
实操建议：
- 目标字段类型优先选
timestamptz，避免手动转换 - 若必须写入
timestamp（无时区），先显式转：(CURRENT_TIMESTAMP AT TIME ZONE 'Asia/Shanghai')::timestamp - 注意
AT TIME ZONE是双向操作：对timestamptz用是转成本地时间字面量；对timestamp用是把它当作某时区的时间再转成timestamptz
真正麻烦的不是语法，而是团队对“这个时间字段到底代表什么”没有共识——是用户手机上看到的时间？服务器日志时间？还是统一协调世界时？一旦语义模糊，任何转换逻辑都会在某次部署后突然失效。
