1

我知道，与 DateTime 相比，引用单个时间点 DateTimeOffset 是更好、更可靠的方法，因为它用一个更方便的东西替换 .Kind 属性，即 Offset to UTC。

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

谢谢

4

1 回答 1

1

给定 a DateTimeOffset，永远不会混淆它代表什么时间点。所以他们总是可靠的。

但是在某些情况下，DateTimeOffset单独使用 a 仍然不够。这是一个常见情况的示例：

  • 您于 2013 年 3 月 10 日在美国纽约。
  • 您会了解当地时间凌晨 1:00 发生的事件。
  • 您将其记录为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 是否生效，都会使用相同的值。（没有带有Idof 的Windows 时区"Eastern Daylight Time"）。TimeZoneInfo此外，没有将 a与 a配对的内置类或结构DateTimeOffset。你必须自己做。

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

您还应该参考DateTime 与 DateTimeOffset。您应该会发现那里的类比非常有用。

也有一些DateTimeOffset不合适的情况。也许这一点很明显，但仍然值得一提。

  • 当您指的不是单个时间点，而是日历上的一个相对点时。

这种情况发生的频率比你想象的要多。例如：

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

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

  • 日界限（“今天”、“昨天”、“明天”）
  • 其他完整命名的日子（“本周三”、“上周五”）
  • 电视节目（“周二晚上 7 点”）
  • 电话通话计划（“免费夜晚和周末”）
  • 还有无数...

在 Noda Time 中，您可以将 aLocalDateTime用于这些场景。如果没有 Noda Time，您将使用DateTimewith .Kind == Unspecified。

于 2013-06-17T21:18:02.433 回答