如果我尝试：
DateTime.Now.Subtract(DateTime.UtcNow)
我希望结果非常接近于零。但事实并非如此，相反，它是时区差异，在我的情况下，是-4小时。有一个.Kind - DateTime知道时区是不同的。为什么我不跟踪这个？是否有正确使用Kind的Subtract的味道？
（作为参考，可以在https://stackoverflow.com/a/3229429/237091看到每个输出的详细信息）
答案 0 :(得分：6)
嗯？ Kind属性不会更改日期数学。它仅用于时区方法。
你得到了我期望你得到的结果。不确定我理解为什么你期待零。
答案 1 :(得分：4)
有一个.Kind - DateTime知道时区是不同的。为什么不为我追踪这个？
因为DateTime is fundamentally broken（and there's more...）。 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，{{1}的想法}和OffsetDateTime，并且不允许你执行非感性算术。我们的目标是提供比BCL更健全的API。当然，这并不一定意味着我们已经成功了。）
答案 2 :(得分：0)
每个DateTime对象代表一个本地时间（而不是UTC时间加上时区偏移）。即使Kind属性等于UTC，它也只是将本地时间存储在零时区。如果不是当地时间，则没有理由UtcNow属性。
DateTime甚至不存储时区。如果Kind等于UTC，那么至少你知道它的时区为零，但如果Kind是本地的或未指定的，则无法知道时区（Kind属性等于{{ 1}}默认情况下）。
因此，Unspecified方法无法将时区合并到计算中，因为时区未知。