<p>结论：C# 中跨时区计算应使用 DateTimeOffset 而非 DateTime，因 DateTime 缺乏时区上下文易致解析错误；推荐统一用 UTC 存储，转换时借助 TimeZoneInfo，避免混用类型及硬编码偏移。</p>
直接说结论：C# 里别用 DateTime 做跨时区计算，该换 DateTimeOffset 就换，否则迟早出错——比如用户在东京下单，后台按本地时间解析成 DateTime.Now 存数据库，结果凌晨三点的订单被当成下午三点处理。
为什么 DateTime 不适合时区转换
DateTime 的 Kind 属性只有 Unspecified、Local、Utc 三种状态，它不记录“这个时间属于哪个时区”，只靠 Kind 猜。一旦你从 API 拿到带时区偏移的时间字符串（如 "2024-05-20T14:30:00+09:00"），用 DateTime.Parse 解析后 Kind 很可能变成 Unspecified，后续调用 .ToUniversalTime() 就会按本地时区硬转，结果错得离谱。
实操建议：
- 所有外部输入（JSON、HTTP Header、表单）的时间，优先用
DateTimeOffset.Parse或DateTimeOffset.TryParse解析 - 数据库字段类型尽量用
datetimeoffset（SQL Server）或带时区的类型（PostgreSQL 的timestamptz），别存datetime - 如果必须用
DateTime，务必在注释里写清它的Kind含义，且禁止在逻辑中混用不同Kind的值做运算
DateTimeOffset 转本地时间或指定时区时间
DateTimeOffset 自带偏移量（如 +08:00），所以它知道“此刻在东八区是几点”，但注意：它不等于“时区”——它没包含夏令时规则，只是个带偏移的快照。要转成某个具体时区（比如 “Asia/Shanghai”）的本地时间，得用 TimeZoneInfo。
常见错误现象：用 DateTimeOffset.ToLocalTime() 在服务器上跑，结果转成服务器所在时区（比如美国西海岸），而不是用户所在时区。
实操建议：
- 获取目标时区对象：用
TimeZoneInfo.FindSystemTimeZoneById("China Standard Time")（Windows）或TimeZoneInfo.FindSystemTimeZoneById("Asia/Shanghai")（.NET 6+ 跨平台） - 转换：用
TimeZoneInfo.ConvertTime(<code>dto,targetZone)，不是dto.DateTime再转 - 避免硬编码偏移：不要用
dto.AddHours(-8)代替时区转换，夏令时会翻车
从 DateTimeOffset 提取 UTC 时间并安全存储
系统内部统一用 UTC 是最稳妥的做法。但 DateTimeOffset.UtcDateTime 返回的是 DateTime 类型，Kind 固定为 Utc，这点很关键——它可安全传给 Entity Framework、Serilog、或者序列化为 ISO 8601 字符串（.ToString("o")）。
使用场景：日志打点、消息队列时间戳、数据库写入。
实操建议：
- 入库前一律走
dto.UtcDateTime，别存dto.DateTime - 需要还原原始偏移时，额外存一个
dto.Offset（TimeSpan类型），比如存进另一列或 JSON 字段 - API 返回给前端时，用
dto.ToString("o")，它会输出类似"2024-05-20T06:30:00.0000000+00:00"的完整带偏移格式，前端Date构造函数能正确识别
跨时区比较和计算的坑
两个 DateTimeOffset 直接用 >、- 运算是安全的，因为它们内部都转成 UTC 刻度再比。但如果你混用 DateTimeOffset 和 DateTime，就容易掉坑。
典型错误：把 DateTimeOffset 和 DateTime.UtcNow 相减，得到的 TimeSpan 可能偏差一整天（因为 DateTime.UtcNow 的 Kind 是 Utc，而 DateTimeOffset 会先转成 UTC 再算，但若 DateTime 是 Unspecified，.NET 会误判为本地时间）。
实操建议：
- 所有比较/计算统一用
DateTimeOffset，哪怕一方是当前时间，也用DateTimeOffset.UtcNow而非DateTime.UtcNow - 加减天数用
dto.AddDays(1)，它会保留原始偏移；如果用dto.DateTime.AddDays(1)，再转回DateTimeOffset就丢了偏移 - 注意
DateTimeOffset.Now返回的是本地时区偏移，不是系统默认时区——它取决于运行机器的设置，别当“服务器时区”用
最常被忽略的一点：时区 ID 在 Windows 和 Linux/macOS 上不完全一致，比如 "China Standard Time" 在 Linux 上会抛 TimeZoneNotFoundException。跨平台部署时，优先用 IANA 时区名（"Asia/Shanghai"），并确认 .NET 版本 ≥ 6，否则得自己映射。
