CONVERT_TZ在MySQL中常返回NULL的根本原因是时区表未加载或时区名不被识别；需检查mysql.time_zone_name表并手动加载时区数据，且须使用IANA标准格式（如Asia/Shanghai）而非缩写。
CONVERT_TZ在MySQL中为什么经常返回NULL
根本原因是时区表没加载，或者传入的时区名不被MySQL识别。比如写 CONVERT_TZ(NOW(), 'UTC', 'Asia/Shanghai') 却返回 NULL，大概率不是函数用错了，而是MySQL压根不知道 Asia/Shanghai 是啥。
检查方式很简单：
SELECT * FROM mysql.time_zone_name LIMIT 5;如果结果为空，说明时区表是空的。这时得手动加载：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql（路径可能因系统而异，
/usr/share/zoneinfo 是Linux常见位置；macOS用 /var/db/timezones/zoneinfo；Windows需下载预编译时区SQL文件）。
- 时区名必须严格匹配
mysql.time_zone_name.Name字段值，CST、PDT这类缩写不可靠，优先用Region/City格式（如America/New_York） -
CONVERT_TZ第一个参数不能是字符串字面量（如'2023-01-01'），必须是datetime类型值；若原始字段是字符串，先用STR_TO_DATE转换 - 该函数在MySQL 8.0+支持更全，5.7及以前对夏令时处理较弱，跨夏令时边界转换可能出错
AT TIME ZONE只在PostgreSQL和SQL Server里有，MySQL不支持
很多开发者搜“SQL AT TIME ZONE”后直接套到MySQL里，结果报错 FUNCTION xxx.AT TIME ZONE does not exist。这不是语法写错，是根本不存在——MySQL至今（截至8.4）没有 AT TIME ZONE 操作符。
PostgreSQL用法示例：
SELECT '2023-01-01 12:00:00'::timestamptz AT TIME ZONE 'Asia/Shanghai';SQL Server则是：
SELECT CAST('2023-01-01 12:00:00' AS datetime2) AT TIME ZONE 'UTC' AT TIME ZONE 'China Standard Time';
- PostgreSQL中，
AT TIME ZONE会自动识别输入是否带时区信息：无时区时间按本地时区解释，有时区则做转换 - SQL Server的时区名用的是Windows时区ID（如
China Standard Time），不是IANA名，查可用列表得执行SELECT * FROM sys.time_zone_info - 三者语法看似相似，但语义差异大：MySQL的
CONVERT_TZ是纯函数调用；PostgreSQL和SQL Server的AT TIME ZONE是类型转换操作符，绑定在数据类型行为上
跨数据库写时区安全SQL的现实妥协方案
真要兼容MySQL、PostgreSQL、SQL Server，别指望一条SQL通吃。最可行的是把时区逻辑提到应用层，数据库只存UTC时间，由代码做转换。
如果非要在SQL里处理，可按数据库分支写条件逻辑：
- MySQL：坚持用
CONVERT_TZ(col, '+00:00', 'Asia/Shanghai')，避免依赖系统时区名，改用偏移量（如'+08:00'）更稳定，但会丢失夏令时信息 - PostgreSQL：用
col AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'，注意字段类型要是timestamptz或显式转成它 - SQL Server：用
col AT TIME ZONE 'UTC' AT TIME ZONE 'China Standard Time'，且确保SQL Server版本 ≥ 2016
另一个底线方案：所有入库时间统一转成UTC字符串（如 '2023-01-01T04:00:00Z'），查询时不转换，仅在展示层格式化——这样既绕开数据库差异，也避免存储歧义。
时区转换最容易被忽略的隐性陷阱
很多人以为只要函数能跑出结果，就万事大吉。实际上，真正难缠的问题藏在细节里：
- MySQL的
CONVERT_TZ对DATETIME和TIMESTAMP行为不同：TIMESTAMP存储时自动转为UTC，读取时再转回会话时区，叠加CONVERT_TZ可能双重转换 - PostgreSQL中，
timestamptz类型字段存的是UTC时间，但显示受timezone参数影响，SELECT now()返回值看起来像本地时间，其实底层仍是UTC - 夏令时切换日（如美国3月第二个周日）前后一小时内，某些时间在本地时区“不存在”或“重复”，
AT TIME ZONE和CONVERT_TZ的处理策略不一致，测试必须覆盖这类边界日期
时区不是格式问题，是时间语义问题。哪怕函数调用成功，输出结果是否符合业务预期，还得拿真实时点去对齐UTC时间戳验证。
