3

If I try:

DateTime.Now.Subtract(DateTime.UtcNow)

I would expect the result to be very close to zero. But it's not, instead it's the time zone difference, in my case, -4 hours. There is a .Kind -- the DateTime KNOWS the timezones are different. Why doesn't it track this for me? Is there a flavor of Subtract that DOES use Kind correctly?

(For reference, a good rundown of what each one outputs can be seen at: https://stackoverflow.com/a/3229429/237091)

4

3 回答 3

6

诶？该Kind属性不会更改日期数学。它仅由时区方法使用。

你得到的结果正是我期望你得到的。不知道我理解你为什么期待零。

于 2012-08-21T19:54:13.170 回答
4

有一个 .Kind - DateTime 知道时区不同。为什么它不为我跟踪这个？

因为DateTime从根本上被破坏了（还有更多......）。如果您尝试从另一种值中减去一种值，IMO 应该会抱怨。但不，它只是在每个值中使用未解释的日期/时间。Kind不幸的是，实际上很少有操作会注意到. （如果您使用TimeZoneInfo，这些操作会注意到它。）

Kind被入侵.NET 2.0；在此之前，一个DateTime值甚至不知道它是什么类型 - 如果你使用：

dt = dt.ToLocalTime().ToLocalTime().ToLocalTime();

它将多次应用相同的偏移更改。BCL 团队在二进制表示中找到了几个备用位，并将其用于Kind.

基本上，我能感觉到你的痛苦。如果这样的操作引发异常，我个人更喜欢它 -DateTime从本地减去 UTC，DateTime反之亦然，IMO 没有什么意义。

作为一个完全有偏见的插件，您可以使用Noda Time来区分 、 、 、 和 的概念Instant，LocalDate并且LocalTime不会让LocalDateTime您执行无意义的算术。我们的目标是提供一种比 BCL 更健全的 API。当然，这并不一定意味着我们已经成功了：）OffsetDateTimeZonedDateTime

于 2012-08-21T19:56:42.760 回答
0

每个DateTime对象代表一个本地时间（而不是 UTC 时间加上时区偏移）。即使该Kind属性等于 UTC，它也只是将本地时间存储在零时区。如果不是当地时间，就没有UtcNow财产的理由。

DateTime 甚至不存储时区。如果Kind等于 UTC，那么至少您知道它的时区为零，但如果Kind是本地或未指定，则无法知道时区（该Kind属性默认为等于Unspecified）。

因此，该Subtract方法不能将时区纳入其计算，因为时区是未知的。

于 2012-08-21T19:56:47.750 回答