数据库层时区转换风险高，应优先在应用层统一用utc；sql server需用todatetimeoffset构造datetimeoffset再at time zone；mysql需确保time_zone_name表已加载；postgresql的at time zone是解释操作而非转换操作，须分步处理。
直接结论：数据库层做时区转换风险高，优先在应用层统一用 UTC；必须在存储过程中处理时区时，SQL Server、MySQL、PostgreSQL 的实现逻辑完全不同，不能套用同一套写法。
SQL Server 存储过程里 AT TIME ZONE 为什么总返回 NULL？
根本原因是 AT TIME ZONE 只接受 DATETIMEOFFSET 类型输入，而你传进去的很可能是 DATETIME2 或 GETDATE() 这类无时区类型——SQL Server 不会猜它属于哪个时区，直接返回 NULL。
- 错误写法：
SELECT GETDATE() AT TIME ZONE 'China Standard Time'→ 返回NULL - 正确路径：先用
TODATETIMEOFFSET(@local_time, '+08:00')或TODATETIMEOFFSET(@local_time, @source_tz)构造带时区值 - 源时区名必须用 Windows 时区名（如
'China Standard Time'），'Asia/Shanghai'会报错 - 别依赖
SYSDATETIMEOFFSET()当作用户本地时区——它反映的是当前会话时区，但存储过程可能被纽约、东京、北京三地客户端并发调用
MySQL 存储过程里 CONVERT_TZ 静默失效怎么办？
CONVERT_TZ 返回 NULL 通常不是函数写错了，而是 mysql.time_zone_name 表为空。Docker 镜像、阿里云 RDS、腾讯云 TDSQL 等默认不加载时区数据，且不报错。
- 快速验证：
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 是后缀操作符，不是“时间 A → 时区 B → 时区 C”的链式转换器。它默认把输入当作“本地时间”，再按指定时区解释——方向和你想做的“东八区转 UTC”相反。
- 错误理解：
col AT TIME ZONE 'Asia/Shanghai' AT TIME ZONE 'UTC'→ 实际是“把 col 当作上海本地时间，解释成 UTC 时间戳”，不是“上海时间转 UTC” - 正确做法分两步：先用
col AT TIME ZONE 'Asia/Shanghai'得到TIMESTAMPTZ，再用AT TIME ZONE 'UTC'输出为 UTC 字符串 - 新建表字段存业务时间，务必用
timestamptz类型 +CURRENT_TIMESTAMP插入，而不是timestamp without time zone - 已有
timestamp字段且数据按北京时间存入，转换前先确认数据库timezone设置（SHOW timezone;），再显式对齐：col AT TIME ZONE 'Asia/Shanghai'
跨库迁移或混合部署时最易踩的坑
SQL Server 的 datetimeoffset 和 PostgreSQL 的 timestamptz 语义不等价：前者是带偏移的固定值，后者是带时区的 UTC 时间戳。一旦混用，凌晨任务调度、夏令时切换、历史数据比对全会出偏差。
- 不要让不同数据库各自处理时区逻辑，统一由应用层接收用户时区标识（如
'Asia/Shanghai'），转成 UTC 后存入所有库 - 存储过程里不做“自动识别时区”动作——没有可靠方式从一个
DATETIME2值反推它本应属于哪个时区 - 测试时必须覆盖夏令时边界日（如 3 月第二个周日、11 月第一个周日），
DATE_SUB(NOW(), INTERVAL 8 HOUR)这类硬偏移在夏令时下会偏 1 小时
