DateTimeOffset 是带偏移的时间点而非时区；解析需用 TryParseExact 指定 ISO 格式，避免 Parse 退化为 Unspecified；跨时区转换须配合 TimeZoneInfo，不可依赖 ToLocalTime 或硬调 AddHours；数据库存储应确保类型匹配 offset，推荐存 UTC + Offset 分离；夏令时运算必须经 TimeZoneInfo 转换，因 AddXxx 不感知 DST 规则。
DateTimeOffset 不是时区，只是带偏移的时间点；用它做跨时区展示或算术，不配合 TimeZoneInfo 就会出错。
DateTimeOffset.Parse() 为什么总把 +09:00 解析成 Unspecified？
因为 DateTimeOffset.Parse() 对输入格式敏感，遇到模糊字符串（比如只有日期、无偏移、含括号时区名如 "GMT+0800 (CST)"）会退化为 DateTimeKind.Unspecified，再转 DateTimeOffset 就丢失原始偏移。
- ✅ 正确做法：用
DateTimeOffset.TryParseExact()指定 ISO 8601 格式（如"o"或"yyyy-MM-ddTHH:mm:ss.fffK"），并传入CultureInfo.InvariantCulture - ❌ 错误写法：
DateTimeOffset.Parse("2024-05-20T14:30:00GMT+0800")—— 这个字符串根本无法识别 - ⚠️ 注意：浏览器
Intl.DateTimeFormat().formatToParts()返回的时区 ID（如"Asia/Shanghai"）不能直接喂给Parse()，它只认偏移量（+08:00），不认时区名
如何把 DateTimeOffset 转成“用户所在时区”的本地时间？
DateTimeOffset.ToLocalTime() 是错的——它转的是服务器本地时区，不是用户时区。真正要做的，是用 TimeZoneInfo 显式指定目标时区。
- 获取目标时区：
TimeZoneInfo.FindSystemTimeZoneById("Asia/Shanghai")（.NET 6+ 跨平台）或"China Standard Time"（Windows） - 转换调用：
TimeZoneInfo.ConvertTime(dto, targetZone)，不是dto.DateTime.ToLocalTime() - 别用
dto.AddHours(-8)硬调：夏令时切换日（如美国 3 月第二个周日）会直接错一小时 - 如果用户时区不可靠（比如前端伪造），建议只存 UTC + 原始 Offset，展示层按需还原，不主动“转换”
数据库存 DateTimeOffset，EF Core 为什么会丢偏移？
EF Core 默认把 DateTimeOffset 映射为 SQL Server 的 datetimeoffset 类型，但如果你字段类型是 datetime 或 PostgreSQL 的 timestamp without time zone，就会静默截断偏移，只留 DateTime 部分。
- ✅ 正确映射：SQL Server 用
datetimeoffset；PostgreSQL 用timestamp with time zone（注意：语义不完全等价，它会自动转存为 UTC） - ✅ 更稳妥做法：数据库只存
UtcDateTime（DateTimeOffset.UtcDateTime），另加一列存Offset.TotalMinutes（short类型） - ❌ 危险操作：
entity.CreatedAt = DateTimeOffset.Now直接入库 —— 服务器在纽约，用户在北京，这个值的 Offset 是 -04:00，不代表用户真实上下文
DateTimeOffset 做加减法，夏令时会自动处理吗？
不会。所有 AddXxx() 方法只对内部 Ticks 和 Offset 做线性运算，不感知夏令时规则。比如在 Central Time 区域，3 月 9 日凌晨 1:30 加 2.5 小时，结果应该是 5:00（跳过 2:00–3:00 的 DST 切换），但 dto.AddHours(2.5) 会得出 4:00，且 Offset 仍为 -06:00。
- ✅ 正确路径：先用
TimeZoneInfo.ConvertTimeToUtc()转 UTC，加减，再用ConvertTimeFromUtc()转回目标时区 - ✅ 封装结构体（如
TimeZoneTime）强制绑定时间和时区，避免裸用DateTimeOffset做业务算术 - ⚠️ 关键点：偏移量（
Offset）是快照，不是规则；时区（TimeZoneInfo）才包含 DST 规则
最难的从来不是怎么解析一个带 +08:00 的字符串，而是当用户从上海飞到洛杉矶，历史订单的“创建时间”该以哪个偏移展示——DateTimeOffset 存的是那一刻的偏移，不是“用户永久时区”，这点很容易被忽略。
