datetimeoffset 并非万能时区解药，它仅存储带偏移的时间值而不自动转换；真正跨时区处理需依赖 at time zone 等显式函数，并严格区分存储意图、传递类型与时区标识。
DATETIMEOFFSET 为什么不能直接当“万能时区解药”用
很多人以为只要把时间字段换成 DATETIMEOFFSET，跨时区读写就自动正确了——其实不是。SQL Server 的 DATETIMEOFFSET 确实能存偏移量（比如 '2024-06-15 14:30:00 +08:00'），但它不自动做时区转换；它只忠实地存你给的值，查出来也原样返回。真正需要转换时（比如把用户本地时间转成 UTC 存储、再按另一时区显示），得靠显式函数，而不是类型本身。
常见错误现象：SELECT 出来的 DATETIMEOFFSET 值在应用层直接渲染，结果发现巴黎用户看到的是 +02:00 时间，但页面却标着“北京时间”，因为没人告诉数据库或应用“这个值该按哪个时区解释”。
- 存储前必须明确：这是用户提交的本地时间？还是已转为 UTC？还是带偏移的原始输入？
-
GETDATE()和SYSDATETIMEOFFSET()返回值不同：前者是DATETIME（无偏移），后者才是带服务器本地偏移的DATETIMEOFFSET，别混用 - 应用层传入
DATETIMEOFFSET字符串时，如果格式不标准（如缺冒号+0800而非+08:00），SQL Server 会报错Conversion failed when converting date and/or time from character string.
用 SWITCHOFFSET 和 AT TIME ZONE 做安全转换
SWITCHOFFSET 只是机械地改偏移值，不调整时间点本身；AT TIME ZONE 才是真·时区转换函数，它依赖 Windows 时区数据库，能处理夏令时切换。两者用途完全不同，选错会导致时间偏差一小时。
典型使用场景：前端传来用户本地时间 '2024-10-27 02:30:00' 和时区名 'Pacific Standard Time'，后端需转成 UTC 存库：
SELECT '2024-10-27 02:30:00' AS local_time AT TIME ZONE 'Pacific Standard Time' AT TIME ZONE 'UTC'
这行语句先将字符串按 PST 解释（自动识别是否 DST），再转成 UTC 时间戳。注意：AT TIME ZONE 要求输入是 DATETIME2 或 DATETIME，不能直接对 CHAR 用；所以实际要加 CONVERT(DATETIME2, ...)。
-
SWITCHOFFSET(<code>col, '+00:00') 只是把'2024-06-15 14:30:00 +08:00'变成'2024-06-15 06:30:00 +00:00'——时间点没变，只是换了个标签 -
AT TIME ZONE支持的时区名必须是 Windows 时区 ID（如'China Standard Time'），不是 IANA 名（如'Asia/Shanghai'） - SQL Server 2016+ 才支持
AT TIME ZONE；老版本只能靠SWITCHOFFSET+ 手动查偏移表，极易出错
应用层和数据库层职责必须划清
数据库不该承担“猜用户意图”的责任。比如用户在东京提交表单，前端 JavaScript 用 Intl.DateTimeFormat().resolvedOptions().timeZone 拿到 'Asia/Tokyo'，这个信息必须随请求一起传给后端——不能指望 SQL Server 自己从 IP 或语言头里推断。
容易踩的坑集中在参数传递环节：
- ORM（如 Entity Framework）默认可能把
DateTimeOffset当作DATETIME2发送，丢失偏移量，导致入库变成无偏移时间 - 用
SqlParameter传值时，类型必须设为SqlDbType.DateTimeOffset，否则 SQL Server 会静默截断偏移部分 - 查询时若用
WHERE created_at > @input，而@input是DATETIME2类型，比较会丢偏移，结果不可靠
一个最小验证方式：插入后立刻查 SELECT created_at, DATEPART(TZOFFSET, created_at) FROM ...，确认偏移值被真实保存。
时区缩写（CST、PST）根本不能用于计算
绝对不要在代码或 SQL 中用 CST、PST 这类缩写做转换。它们歧义太大：CST 可能指 China Standard Time、Central Standard Time，甚至 Cuba Standard Time；PST 在非夏令时期是 Pacific Standard Time，但夏令时其实是 PDT——而缩写本身不携带 DST 规则。
Windows 时区名（如 'China Standard Time'、'Pacific Standard Time'）是唯一被 AT TIME ZONE 支持的标识，它们背后绑定完整时区规则表。哪怕名字里带 “Standard”，SQL Server 也会根据日期自动切到 DST 版本。
- 前端传时区名时，别用
new Date().toString().match(/([A-Z]+)$/) [1]提取缩写——这在夏令时切换日当天可能返回错误结果 - 服务端配置文件里写死
"timezone": "CST"是危险的，应统一用 IANA 时区名（如Asia/Shanghai），并在接入 SQL Server 前映射为 Windows ID - SQL Server 不提供 IANA 到 Windows 的映射表，这部分必须由应用自己维护（微软官方有映射文档，但需手动同步）
跨时区时间同步真正的难点不在语法，而在整个链路中每个环节都得明确“这个时间值代表什么、以谁的视角解释”。哪怕 DATETIMEOFFSET 存对了，前端没按正确时区渲染，用户看到的还是错的。
