SQL查询中如何处理时区转换问题：使用CONVERT_TZ或AT TIME ZONE
CONVERT_TZ在MySQL中为什么经常返回NULL
这事儿其实挺常见：你照着文档写了句 CONVERT_TZ(NOW(), 'UTC', 'Asia/Shanghai')，结果返回一个冷冰冰的 NULL。先别急着怀疑语法，问题大概率出在数据库本身——MySQL压根不认识你给的时区名。
怎么验证呢？方法很简单：
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的第一个参数必须是datetime类型。如果你手头是个字符串字面量（比如'2023-01-01'），得先用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月的第二个周日），前后一小时内可能会出现某个本地时间“不存在”（跳过了）或者“重复出现”（出现了两次）的情况。不同的数据库（甚至同一数据库的不同函数）对这类边界时间的处理策略可能不一致。测试用例必须覆盖这些特殊的日期，否则线上就可能出bug。
说到底，时区问题从来不只是个简单的格式转换。它关乎时间的语义本身。即便函数调用成功返回了结果，你也得拿着真实的UTC时间戳去反推验证，看看这个结果是否符合你的业务逻辑预期。这一步验证，千万不能省。
