应统一使用UTC存储时间，并通过TimeZoneInfo进行时区转换，结合DateTimeKind和DateTimeOffset确保时间上下文准确，再按用户文化格式化显示。
在 .NET 中进行日期时间处理时，若应用面向全球用户，必须考虑不同时区、文化差异和夏令时变化。忽略这些因素可能导致时间显示错误、日志混乱或业务逻辑出错。
正确使用 TimeZoneInfo 处理时区
.NET 提供 TimeZoneInfo 类来支持多时区转换。不应依赖本地系统时间或硬编码偏移量，而应通过标准时区标识符（如 "Asia/Shanghai" 或 "America/New_York"）进行操作。
示例：将 UTC 时间转换为用户所在时区：
var utcTime = DateTime.UtcNow;var userTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Tokyo Standard Time");
var localTime = TimeZoneInfo.ConvertTimeFromUtc(utcTime, userTimeZone);
注意：Windows 和 Linux 系统上的时区 ID 可能不同（如 Linux 使用 IANA 名称），.NET 6+ 支持映射 IANA 与 Windows 时区名，建议使用 TimeZoneInfo.FindSystemTimeZoneById 并配合时区映射表。
区分 DateTime.Kind 的使用场景
DateTime 的 Kind 属性（Utc、Local、Unspecified）直接影响转换行为。处理跨时区数据时务必明确设置 Kind，否则可能引发误转换。
- 存储和传输统一使用 UTC，并标记为 DateTimeKind.Utc
- 前端传来的本地时间应标记为 Unspecified，再结合用户时区转为 UTC 存储
- 避免对 Unspecified 时间直接调用 ToLocalTime() 或 ToUniversalTime()
使用 DateTimeOffset 替代 DateTime 传递上下文
DateTimeOffset 包含时间偏移信息，更适合记录带时区上下文的时间点。例如日志记录、API 输入输出等场景，使用它可避免歧义。
示例 API 模型中使用：
public class EventDto{
public DateTimeOffset OccurredAt { get; set; }
}
这样无论客户端在哪个时区，服务端都能准确还原原始时间点。
格式化与解析需指定文化信息
不同地区对日期格式习惯不同（如 MM/dd/yyyy vs dd/MM/yyyy）。应根据用户文化进行格式化，避免使用默认的当前线程文化。
- 格式化显示时使用 ToString(format, culture)
- 解析字符串时使用 DateTime.ParseExact 或 DateTimeOffset.Parse 并传入目标 CultureInfo
- Web 应用可通过 Accept-Language 头或用户设置确定文化
基本上就这些。关键是统一存储用 UTC，展示按用户时区，传递带偏移或明确时区，格式化尊重文化习惯。这样能有效避免全球化下的时间混乱问题。
