是否有任何DateTimeOffset可能不可靠的情况？

Question

据我所知，引用单个时间点DateTimeOffset与DateTime相比更好更可靠，因为它取代了.Kind属性更方便的东西，即UTC的偏移量。

这是否解决了在日期时间中存储单个点的所有问题，还是仍有一些我应该关注的情况？ （如果有可以给我一些DateTimeOffset不可靠的例子吗？）

由于

Answer 1

鉴于DateTimeOffset，对于代表什么时间点，从来没有任何混淆。所以他们总是可靠。

但在某些情况下，DateTimeOffset单独仍然足够。以下是一个常见情况的示例：

• 您于2013年3月10日在美国纽约。
• 您可以了解当地时间凌晨1点发生的事件。
• 您将其记录为DateTimeOffset，其值为2013-03-10T01:00:00-05:00。
• 稍后，您会发现您收到的信息不正确，事件实际发生在凌晨3:00。
• 因此，您要进行编辑，并将值更改为2013-03-10T03:00:00-05:00。
• 但这不正确。在该特定日期，夏令时开始，因此凌晨3:00比凌晨1:00仅晚一个小时。如果您只是提前花时间而不考虑偏移量可能已经改变，那么您就是在引用错误的时间点。
• 应 2013-03-10T03:00:00-04:00。

要克服这种情况，您必须也知道时间是在纽约录制的。你知道在第一步中，但是当你录制它时它就被抛弃了。在你的应用程序的其他地方，你必须坚持这个事实。您最好保留时区ID，以便重新计算正确的偏移量。

如果在您的应用程序中使用TimeZoneInfo类，那么您需要跟踪.Id属性的值以及DateTimeOffset。对于纽约，时区ID为"Eastern Standard Time"。这有点令人困惑，因为无论DST是否生效，都会使用相同的值。 （没有Id "Eastern Daylight Time"的Windows时区。此外，没有内置的类或结构将TimeZoneInfo与DateTimeOffset配对。你必须自己做。

如果您使用Noda Time（我强烈推荐）。然后，您可以利用IANA时区ID "America/New_York"和ZonedDateTime对象 - 这是针对这种情况设计的。

您还应该参考DateTime vs DateTimeOffset。你应该找到相似的类比。

---

在某些情况下，DateTimeOffset不合适。也许这个很明显，但仍然值得一提。

• 如果不指的是单个时刻，而是日历上的相对点。

这种情况比您想象的更频繁。例如：

• 在美国，今年的夏令时开始于2013年3月10日凌晨2点。
• 但它并没有在同一时刻发生。每个时区都有自己的本地凌晨2点，所以在瞬时时间线上实际上有几个不同的转换点。
• （除此之外，值得一提的是，在欧洲，DST（“夏令时”）一下子发生。转换基于西欧，中欧和东欧时间的相同UTC时刻。）

还有其他现实世界的例子，日历上的相同点是而不是同一时间点，但人们倾向于认为它们就像它们一样。

• 日界（“今天”，“昨天”，“明天”）
• 其他整个命名日（“本周三”，“上周五”）
• 电视节目（“星期二晚上7点”）
• 电话通话计划（“免费住宿和周末”）
• 无数其他人......

在Noda Time中，您将使用LocalDateTime来表示这些情况。如果没有Noda Time，您可以使用DateTime .Kind == Unspecified。