sql server 中 at time zone 返回 null 是因未用 todatetimeoffset 显式标注时区；mysql convert_tz 失效常因 time_zone_name 表为空；postgresql 需两步 at time zone 才能正确转换；跨库时区逻辑应由应用层统一处理 utc，数据库只存 utc。
AT TIME ZONE 在 SQL Server 存储过程中不能直接套用无时区时间，必须先用 TODATETIMEOFFSET 显式打上源时区标签，否则结果不可靠。
SQL Server 存储过程里用 AT TIME ZONE 为什么总返回 NULL？
常见错误是直接对 DATETIME2 或 GETDATE() 调用 AT TIME ZONE。SQL Server 不会自动推断这个时间属于哪个时区，它只接受 DATETIMEOFFSET 类型或已明确带偏移的值。
-
SELECT GETDATE() AT TIME ZONE 'China Standard Time'→ 返回NULL - 正确写法：先用
TODATETIMEOFFSET(@local_time, '+08:00')或TODATETIMEOFFSET(@local_time, @source_tz)构造带时区值 - 若源时区来自参数（如用户提交的“北京时间”），必须传入 Windows 时区名（
'China Standard Time'），不是 IANA 名（'Asia/Shanghai'会报错） - 服务器本地时区（
SYSDATETIMEOFFSET()）不能替代源时区——存储过程可能被不同时区客户端调用，会话上下文不可信
MySQL 存储过程中 CONVERT_TZ 为什么经常静默返回 NULL？
根本原因不是函数写错，而是 mysql.time_zone_name 表为空。Docker 镜像、云数据库（如阿里云 RDS）、精简版安装默认不加载时区数据，CONVERT_TZ 就会失效且不报错。
- 测试是否可用：
SELECT CONVERT_TZ(NOW(), '+08:00', '+00:00');返回NULL就说明缺失 - 加载方式（Linux）：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql - 时区名必须严格匹配
mysql.time_zone_name.Name字段，CST、PDT这类缩写不可靠，优先用America/New_York格式 - 第一个参数不能是字符串字面量（如
'2024-01-01'），得是DATETIME类型；若字段是字符串，先用STR_TO_DATE()转换
PostgreSQL 存储过程里 AT TIME ZONE 的链式调用怎么写才对？
PostgreSQL 的 AT TIME ZONE 是后缀操作符，不是 SQL Server 那种链式转换器。它默认把输入当作“本地时间”，再按指定时区解释——这和你想做的“东八区时间转 UTC”方向相反。
- 错误写法：
SELECT '2024-06-01 12:00'::TIMESTAMP AT TIME ZONE 'Asia/Shanghai';→ 实际得到的是该时间在 UTC 下的等价值 - 正确写法（两步）：
SELECT '2024-06-01 12:00'::TIMESTAMP AT TIME ZONE 'Asia/Shanghai' AT TIME ZONE 'UTC'; - 必须用 IANA 时区名（
'Asia/Shanghai'），Windows 名（如'China Standard Time'）不识别 - 若字段是
TIMESTAMP WITHOUT TIME ZONE，必须显式加AT TIME ZONE 'Asia/Shanghai'对齐语义，否则后续比较或聚合会出错
跨数据库写存储过程时，时区逻辑放哪最稳？
别在 SQL 层拼时区转换逻辑。MySQL、PostgreSQL、SQL Server 的时区名体系、函数行为、夏令时处理全都不兼容，硬写一条通吃 SQL 只会埋坑。
- 真正可控的做法：应用层统一接收带时区的时间（如 ISO 8601 字符串
"2026-07-21T15:30:00+08:00"），立刻转为 UTC 时间点，再以DATETIME(3)或TIMESTAMPTZ存入 - 读取时，也由应用层按需转目标时区——不是靠
CONVERT_TZ或AT TIME ZONE，而是用语言原生时区 API（如 Python 的astimezone()） - 数据库只存 UTC，意味着连接层必须强制设为
+00:00（JDBC 加&serverTimezone=UTC，Python 加timezone='UTC'），避免任何隐式转换干扰 - 如果已有老数据是本地时间且无法改应用，补救方案只能是：在存储过程中用
TODATETIMEOFFSET(col, '+08:00')或CONVERT_TZ(col, '+08:00', '+00:00')强制打标，但得确认所有数据确实都代表同一时区
TIMESTAMP 自动转、还是用 DATETIME 原样存、还是必须上 TIMESTAMPTZ。搞错这个，后面所有转换都是徒劳。
