EF Core 跨时区应优先使用 DateTimeOffset 存储带偏移时间戳，配合数据库对应类型（如 DATETIMEOFFSET）、实体属性声明及应用层转换；避免 DateTime 及 Kind 陷阱；日期/时间单独场景用 DateOnly/TimeOnly。
EF Core 本身不自动处理时区转换，关键在于模型设计 + 数据库存储策略 + 应用层转换逻辑三者配合。直接用 DateTime 存时间，几乎必然出问题；而正确使用 DateTimeOffset 或 DateOnly/TimeOnly，再配合适当的保存与显示方式，就能稳住跨时区场景。
优先用 DateTimeOffset 存带偏移的时间戳
这是解决跨时区写入和读取最直接、最可靠的方式：
-
数据库字段类型要匹配：SQL Server 对应
DATETIMEOFFSET，PostgreSQL 对应timestamp with time zone，MySQL 推荐TIMESTAMP（自动转 UTC）或显式用datetime+ 偏移字段 -
实体属性必须声明为 DateTimeOffset，不要用 DateTime + Kind=Utc 模拟：
public class Order { public int Id { get; set; } public string ProductName { get; set; } public DateTimeOffset OrderTime { get; set; } // ✅ 正确 } -
写入时统一用 UtcNow 或带明确偏移的实例：
- 推荐保存
DateTimeOffset.UtcNow—— 简单、无歧义、便于后续按需转换 - 也可接收前端传来的带偏移时间（如
"2025-12-15T14:30:00+08:00"），EF Core 会原样存入数据库，保留原始上下文
- 推荐保存
读取后按用户时区做显示转换
数据库里存的是“带偏移的时间点”，应用层负责把它变成用户看得懂的本地时间：
- 查询出来仍是
DateTimeOffset，不建议直接 ToString() 显示 - 用
TimeZoneInfo.ConvertTime()转成目标时区：var userZone = TimeZoneInfo.FindSystemTimeZoneById("China Standard Time"); foreach (var order in orders) { var localTime = TimeZoneInfo.ConvertTime(order.OrderTime, userZone); Console.WriteLine($"下单时间（北京时间）：{localTime}"); } - Web API 场景下，可由前端根据
Intl.DateTimeFormat自动格式化，后端只返回 ISO 8601 格式的完整带偏移字符串（如"2025-12-15T06:30:00.0000000+00:00"）
避免 DateTime.Kind 的陷阱
DateTime 的 Kind 属性（Unspecified/Local/Utc）在 EF Core 持久化过程中会被丢弃，数据库里只存值，不存含义：
- 即使你设
dt.Kind == DateTimeKind.Utc，EF Core 写进 SQL ServerDATETIME2字段后，再读回来仍是Unspecified - 这意味着所有基于
.ToUniversalTime()或.ToLocalTime()的转换都可能出错，尤其在服务器跨时区部署时 - 结论：只要涉及多时区业务，实体中就不要用 DateTime 类型表示时间点
特殊场景：仅日期或仅时间
生日、排班开始时间、闹钟设定等，不需要时区，也不该用 DateTime 强行塞：
-
DateOnly（EF Core 6+ 原生支持）→ 对应 SQL Server
date类型，无时区、无时间部分 -
TimeOnly（EF Core 6+ 原生支持）→ 对应 SQL Server
time类型，无日期、无时区 - 它们天然规避了时区转换问题，也节省空间、语义清晰
- 注意：若需“某天上午9点”这种组合，仍应拆为
DateOnly + TimeOnly或用DateTimeOffset表达完整时刻
基本上就这些。核心不是“EF Core 怎么转”，而是“你选对类型了吗？存得准吗？读出来怎么用？”——把这三步理清楚，时区问题就不再是个噩梦。
