2 回答
TA贡献1805条经验 获得超9个赞
从问题评论中的讨论中,我了解到您正在使用航班时刻表-即将来要起飞的时间。实际上,这是当地时间比UTC时间重要的情况。
由于您拥有当地的出发时间和地点(例如:盐湖城的5:00 PM),因此您应该在计划的出发时间数据库中存储两个值:
17:00
-出发当地时间SLC
-与时间相关的位置
如果这是这次航班的特定情况,那么您还应该存储日期:
2018-06-01T17:00
-具体的当地相关出发时间SLC
-与当地时间有关的位置
这些是与业务用例上下文相关的详细信息。不要通过将它们转换为UTC来忽视它们。
就是说,您可以考虑将它们存储为DateTimeOffset
(2018-06-01T17:00-06:00
),这对于给定的实例而言转换为UTC并不重要。但是,此方法存在两个问题:
由于偏移量可能会更改,因此无法重复使用。
即使对于单个实例,偏移量也可能会发生变化-如果控制时区的政府决定在发生这种情况之前更改标准偏移量或夏令时规则。如果您采用一种
DateTimeOffset
方法或基于UTC的方法,则必须准备面对此类变化重新计算未来的事件。(有关此内容的更多信息,请参阅我的博客文章:关于埃及时区变化的时机和不可避免的时区混乱。还有无数其他示例。)
关于位置-因为您正在使用的上下文数据适用于航空业,所以我建议使用SLC
上面显示的IATA机场代码。在其他情况下,可能会存储IANA时区标识符(例如America/Denver
)或Windows时区标识符(例如)Mountain Standard Time
。
您可能会发现我的“机场时区”要点(代码和输出表)对于使用IATA机场代码非常有用。您必须决定这些数据将如何在您的系统中流动。如果您在Windows上运行,并且想使用TimeZoneInfo
该类将时间转换为不同的时区,请使用此处显示的Windows时区ID。如果要使用IANA时区ID,请考虑使用Noda Time,也可以使用我的TimeZoneConverter库。这里有几种不同的选项,因此请仔细研究所有选项,然后选择对您有意义的选项。
恕我直言,野田时间将是一个不错的选择。您不仅会获得出色的时区支持,而且还能够使用类似LocalTime
或LocalDateTime
与所描述的场景非常吻合的类型。
- 2 回答
- 0 关注
- 355 浏览
添加回答
举报