ASP.NET Core中EF Core+PostgreSQL DateTime存储不一致问题咨询

背景 #

在ASP.NET Core项目中使用Entity Framework Core操作PostgreSQL数据库，定义了OrderEntity和OrderItemEntity实体类，Program.cs中配置请求本地化（默认en-IN）。创建订单时逻辑如下：

• OrderDate自动赋值为DateTime.Now
• OrderItem.StartDate由用户传入印度本地时间
• CreatedAt在EF Core保存前通过拦截器设为DateTimeOffset.Now

但本地部署与AWS云环境的PostgreSQL中存储的时间值不一致：同一用户输入（印度时间2023年8月2日14:00创建订单），StartDate、OrderDate在两地数据库存储值存在差异，仅CreatedAt一致。已知DateTime应按UTC存储，针对以下问题给出解答：

1. CreatedAt使用DateTimeOffset.Now存储是否正确？需改为DateTimeOffset.UtcNow吗？ #

必须改为DateTimeOffset.UtcNow。DateTimeOffset.Now获取的是当前服务器的本地时间及对应时区偏移，本地与AWS云服务器的时区大概率不同（比如AWS默认采用UTC时区），虽然存储的是带偏移的时间，但本质是服务器本地时间，存在跨环境不一致的风险。而DateTimeOffset.UtcNow存储的是UTC标准时间（偏移量为+00:00），无论部署环境的时区如何，存储的时间值都是统一的UTC时间，这才是跨环境时间存储的标准做法。

2. OrderDate是改为DateTime.UtcNow，还是将列改为DateTimeOffset类型存储DateTimeOffset.UtcNow？ #

优先选择将列改为DateTimeOffset类型，存储DateTimeOffset.UtcNow，原因如下：

• DateTime类型的Kind属性在EF Core与PostgreSQL交互时容易丢失（PostgreSQL的timestamp类型不带时区信息），后续读取时可能被错误解析为服务器本地时间。
• DateTimeOffset类型本身携带时区偏移信息，存储的UTC时间（偏移+00:00）不会被误解析，跨环境读取时能准确还原为UTC时间，也方便后续转换为任意时区的本地时间。
• 如果暂时无法修改列类型，至少要将OrderDate赋值为DateTime.UtcNow，同时在EF Core配置中明确指定该列的时区属性（比如通过HasColumnType("timestamp with time zone")或配置ValueConverter确保UTC存储），但这种方式的可靠性远不如直接使用DateTimeOffset。

3. 用户输入的本地时间StartDate，需改为DateTimeOffset类型列存储吗？ #

是的，建议改为DateTimeOffset类型存储，具体操作流程：

1. 服务端接收用户传入的印度本地时间后，先将其转换为包含印度时区偏移（+05:30）的DateTimeOffset对象。
2. 存储时可选择两种方式：要么将其转换为UTC时间（startDateOffset.UtcDateTime对应的DateTimeOffset，即2023-08-02 08:30+00:00）存入数据库，要么直接存储带原始偏移的DateTimeOffset值——PostgreSQL的timestamptz类型支持存储带时区偏移的时间，两种方式都能保证跨环境一致性。
3. 如果继续使用DateTime类型存储，用户传入的本地时间转换为UTC后存入，但DateTime的Kind信息容易丢失，后续读取时可能被错误解析为服务器本地时间，导致时间显示错误。使用DateTimeOffset不仅能避免这类问题，还能保留原始的时区偏移信息（若业务需要追溯用户操作时的本地时间）。

内容的提问来源于stack exchange，提问作者fingers10