.NET 7 Razor页面多国家应用中日期时间与时区处理问题

1. SQL Server时间类型选择 #

优先使用datetimeoffset类型存储所有时间数据，原因如下：

• DateTime不包含时区信息，存储后无法明确其归属时区，后续转换极易出现歧义；
• datetimeoffset会保留时区偏移量，能精准记录时间的原始时区属性，不管是管理员设置的可预约时段，还是用户提交的预约时间，存储后都能准确追溯和转换。
  如果受限于旧系统必须使用DateTime，则所有存储的时间必须统一为UTC，且业务层要严格保证写入时均转换为UTC，读取时再转成对应时区的本地时间。

2. 可靠的时区转换实现 #

.NET的TimeZoneInfo就是可靠的解决方案，之前出现问题大概率是使用方式有误，正确用法示例：

• 将用户本地时间转换为UTC：

  // 从数据库取出用户的时区ID，例如"Central Asia Standard Time"（对应+05:30）
  TimeZoneInfo userTimeZone = TimeZoneInfo.FindSystemTimeZoneById(userTimeZoneId);
  DateTime userLocalTime = new DateTime(2024, 5, 20, 10, 0, 0);
  DateTime utcTime = TimeZoneInfo.ConvertTimeToUtc(userLocalTime, userTimeZone);
  

• 将UTC时间转换为管理员本地时区：

  TimeZoneInfo adminTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Iran Standard Time"); // 对应+3:30
  DateTime adminLocalTime = TimeZoneInfo.ConvertTimeFromUtc(utcTime, adminTimeZone);
  

注意：必须使用时区ID（如"Iran Standard Time"）而非硬编码偏移量，因为时区ID会自动处理夏令时的偏移变化。

3. 夏令时与系统设计合理性 #

夏令时必须重点考虑，尤其是跨时区的预约业务。你提到TimeZoneInfo.ConvertTimeToUtc()不考虑夏令时是错误的，只要传入正确的TimeZoneInfo对象，该方法会自动处理夏令时的偏移调整。

最优设计方案：所有时间（包括管理员配置的时段、用户预约时间）统一存储为UTC：

• 管理员设置可预约时段时，先将本地的8:00-20:00转换为UTC存储，例如+3:30时区的8:00转成UTC的4:30，20:00转成UTC的16:30；
• 用户提交预约时，将自身本地时间转换为UTC存储；
• 展示时，再将UTC时间转换为对应角色（管理员/用户）的本地时区时间。
  这种方式能彻底规避时区和夏令时带来的混乱，所有计算基于UTC，不会出现时间歧义。

如果之前使用内置方法出错，可检查以下几点：

• 是否使用了正确的时区ID，而非自定义的固定偏移量；
• 转换时DateTime对象的Kind属性是否正确（Unspecified可能导致转换错误，建议明确指定或使用DateTimeOffset类型）；
• 是否测试了夏令时切换时段的边界情况，比如切换前后的时间转换是否准确。

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