NodaTime 比 DateTime 更诚实：它强制显式处理时区、夏令时和时间语义，用 ZonedDateTime 封装 Instant/DateTimeZone/CalendarSystem，解析和序列化均保留完整上下文，杜绝静默错误。
因为 DateTime 在语义上不明确、时区处理脆弱、夏令时行为隐式且易出错，而 NodaTime 强制你面对时间建模的复杂性——不是“更高级”，而是“更诚实”。
DateTime 的“本地时间”到底是什么？
DateTime.Kind 只有 Unspecified、Local、Utc 三种标记，但 Local 实际依赖运行时机器的时区设置，无法序列化/反序列化为可重现的含义。比如：
- 服务器在纽约、客户端在东京，
DateTime.Now都叫Local，但代表完全不同的瞬时（instant） -
DateTime.ToUniversalTime()在Kind == Unspecified时会**静默按本地时区解释**，极易误转 - 跨时区调度任务时，用
DateTime表达“每周三 9:00 纽约时间”，代码里根本看不出“纽约”，只有一堆.AddHours()补丁
ZonedDateTime 是 NodaTime 处理真实世界时间的核心
ZonedDateTime 明确封装了三个要素：一个 Instant（绝对时间点）、一个 DateTimeZone（如 DateTimeZoneProviders.Tzdb["America/New_York"]）、一个 CalendarSystem（默认 ISO）。它让你无法回避“这个时间属于哪个地区”的问题。
例如表达“2025-03-15 09:00 在纽约”：
var zone = DateTimeZoneProviders.Tzdb["America/New_York"];
var zdt = new LocalDateTime(2025, 3, 15, 9, 0)
.InZoneLeniently(zone); // 或 InZoneStrictly() 主动失败而非静默修正
后续任何转换（如转 UTC、转东京时间）都基于明确的时区规则，包括夏令时跳变逻辑——由 TZDB 数据库保障，不是靠 Windows 注册表或 TimeZoneInfo 的有限缓存。
Parse 和 Format 默认不接受模糊输入
DateTime.Parse("2024-05-20") 会返回 Kind == Unspecified，你得自己猜它本意是本地还是 UTC；而 NodaTime 的解析器要求显式指定上下文：
-
LocalDatePattern.Iso.Pattern.Parse("2024-05-20")→ 得到纯日期，不含时区也不含时间 -
ZonedDateTimePattern.CreateWithInvariantCulture("yyyy-MM-dd HH:mm:ss;zzz", DateTimeZoneProviders.Tzdb["UTC"])→ 必须声明时区，否则编译不过 - 没有
DateTime.ParseExact(..., "o")那种看似万能实则埋雷的格式——"o"对Unspecified的处理逻辑在不同 .NET 版本中还变过
序列化时不会丢失语义
DateTime 序列化成 JSON 后只剩一个字符串（如 "2024-05-20T13:45:00"），消费者完全不知道它该被当本地时间、UTC 还是某个特定时区的时间解析；而 NodaTime 类型默认序列化带类型标识（如 {"date":{"year":2024,"month":5,"day":20}}）或严格 ISO 格式（ZonedDateTime 输出带 [UTC] 或 [America/New_York] 后缀），配合 NodaTime.Serialization.JsonNet 或 System.Text.Json 的转换器，语义全程可追溯。
真正难的不是写对一行 ZonedDateTime 调用，而是团队里没人再敢写 DateTime.Now.AddHours(8) 来“凑”另一个时区的时间——那行代码本身就在掩盖问题。
