SQL Server中AT TIME ZONE对DATETIME等无时区类型返回NULL，因静默转为无偏移的DATETIME2后无法推断源时区；PostgreSQL的AT TIME ZONE是后缀操作符，需链式调用实现时区转换；MySQL用CONVERT_TZ()但依赖预加载时区表；跨库最大陷阱是Windows与IANA时区名不互通及夏令时处理差异。
AT TIME ZONE在SQL Server中为什么经常返回NULL
SQL Server的AT TIME ZONE只能作用于DATETIMEOFFSET或DATETIME2类型，如果对DATETIME或SMALLDATETIME直接使用，会静默转成DATETIME2但**不带时区信息**，再执行AT TIME ZONE时因源值无时区上下文，SQL Server无法推断原始时区，最终返回NULL。
常见错误写法：
SELECT GETDATE() AT TIME ZONE 'China Standard Time'; -- 返回 NULL
正确做法是先显式转换为带精度的DATETIME2，再指定源时区（注意：这步必须明确告诉SQL Server“这个时间原本属于哪个时区”）：
- 用
TODATETIMEOFFSET把本地时间打上时区标签，例如TODATETIMEOFFSET(GETDATE(), '+08:00') - 或先用
SYSDATETIMEOFFSET()获取当前服务器带时区的时间，再转换目标时区 - 若数据来自
DATETIME列且已知其固定代表东八区，则必须手动补偏移：TODATETIMEOFFSET(your_datetime_col, '+08:00') AT TIME ZONE 'UTC'
PostgreSQL里没有AT TIME ZONE语句怎么办
PostgreSQL确实有AT TIME ZONE，但它不是T-SQL那种链式操作符，而是**一元后缀操作符**，语法和语义都不同：它把输入值当作“本地时间”去解释，并按指定时区转换为TIMESTAMP WITH TIME ZONE（即TIMESTAMPTZ）。
典型误用：
SELECT '2024-06-01 12:00'::TIMESTAMP AT TIME ZONE 'Asia/Shanghai'; -- 得到的是 UTC 时间戳
这是因为PostgreSQL默认把'2024-06-01 12:00'::TIMESTAMP当成“服务器本地时间”，再把它按Asia/Shanghai解释——实际结果是该时间在UTC下的等价值。要真正做“东八区时间转UTC”，应：
- 先转成
TIMESTAMPTZ：用'2024-06-01 12:00'::TIMESTAMP AT TIME ZONE 'Asia/Shanghai'→ 得到TIMESTAMPTZ值 - 再转出目标时区：
(... ) AT TIME ZONE 'UTC'，完整写法：'2024-06-01 12:00'::TIMESTAMP AT TIME ZONE 'Asia/Shanghai' AT TIME ZONE 'UTC' - 注意时区名必须用IANA格式（如
Asia/Shanghai），不能用Windows风格（如China Standard Time）
MySQL如何模拟AT TIME ZONE效果
MySQL 8.0+ 没有AT TIME ZONE，但提供了CONVERT_TZ()函数，它是真正意义上的时区转换函数：接受“源时区”“目标时区”两个字符串参数。
关键限制：
- 依赖系统时区表，需提前运行
mysql_tzinfo_to_sql导入时区数据，否则CONVERT_TZ对命名时区（如'Asia/Shanghai'）返回NULL - 不支持缩写如
CST（歧义太大），必须用全称或+08:00这类偏移量 -
CONVERT_TZ(NOW(), '+08:00', '+00:00')是安全的；但CONVERT_TZ(NOW(), 'Asia/Shanghai', 'UTC')可能失败，除非时区表已加载
示例（确保时区表就绪后）：
SELECT CONVERT_TZ('2024-06-01 12:00:00', 'Asia/Shanghai', 'America/New_York');跨数据库写法兼容性最坑的点是什么
不是语法差异，而是**时区名体系根本不互通**：SQL Server用Windows时区ID（Pacific Standard Time），PostgreSQL/MySQL用IANA（America/Los_Angeles），Oracle又另有一套。同一逻辑在不同库写死时区名，必然出错。
更隐蔽的问题是夏令时处理：SQL Server的AT TIME ZONE自动识别DST规则，但MySQL的CONVERT_TZ()是否生效，取决于你导入的时区表版本；PostgreSQL则完全依赖操作系统时区数据库。
建议做法：
- 业务层统一用UTC存时间，显示/输入时才转本地时区，避免存储层做转换
- 若必须数据库内转换，抽象出视图或函数封装，按数据库类型分发不同实现
- 测试务必覆盖夏令时切换前后各一天，比如3月第二个周日、11月第一个周日
时区转换看着简单，实际踩进偏移算错、DST跳变、名称映射缺失里的概率，远高于语法写错。
