MongoDB C#存储本地时间：多时区航班时间存储方案咨询

嘿，针对你提到的航班业务场景——需要精准保留不同时区的起飞/到达本地时间，还得避免转UTC丢失时区信息的问题，存储UTC时间+时区偏移量是个可行的临时方案，但绝对不是最优解，下面给你拆解利弊和更靠谱的做法：

• 先说说这个方案的可取之处：
  这种方式确实能在读取时通过UTC时间 + 偏移量还原出当时的本地时间，满足“展示原始时区时间”的基本需求，而且UTC本身是全球统一的时间基准，存储起来不会有歧义，实现起来也简单。

• 但它的致命缺陷你必须重视：
  时区偏移量可不是固定不变的！很多地区有夏令时（DST）调整，同一个时区在不同年份甚至同一年的不同时段，偏移量会变化。举个例子，美国东部时区（EST/EDT）冬季是UTC-5，夏季就变成UTC-4。如果你的航班跨夏令时切换期，或者需要长期存储历史航班数据，只存偏移量的话，后续还原的时间很可能出错——因为你只记录了当时的偏移值，却没记录这个偏移对应的完整时区规则，没法应对未来时区规则变更（比如有些国家突然取消夏令时）的情况。

• 更适合航班业务的最优方案：
  应该存储UTC时间 + IANA时区标识符（比如America/New_York、Asia/Shanghai）。这才是行业内的标准做法，好处太多了：

  1. 完全保留了时区的完整规则，不管夏令时怎么变、时区规则有没有更新，都能通过IANA时区数据库精准还原出对应时区的本地时间；
  2. 航班业务经常涉及跨时区调度、多语言地区查询，用IANA时区能灵活实现各种时间转换（比如把纽约航班时间转成北京本地时间给国内乘客看）；
  3. 现在主流编程语言（Python、Java、JavaScript等）都有成熟的库支持IANA时区处理，比如Python的zoneinfo、Java的java.time.ZoneId，实现成本很低，踩坑也少。

• 额外的小优化建议：
  如果你的系统需要高频展示原始本地时间（比如乘客订票时直接看机场当地时间），可以在存储UTC+IANA时区的基础上，额外冗余存储一份格式化后的本地时间字符串（比如2024-10-01 08:00）。这样查询展示时可以直接用，不用每次都做时间转换，能提升一点性能——但核心的时间数据必须用UTC+IANA时区来存储，冗余字符串只是用于展示优化，不能作为唯一的时间依据。

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