C# 闰年bug调用ToUniversalTime（）.AddYears（）.ToLocalTime（）？

我在.NET的

DateTime

处理中遇到了可能是闰年的问题，特别是

ToLocalTime（）

。下面是一些重现问题的代码（我在太平洋时区）：

输出为：

开始时间：1=2/28/2009 11:00:00 PM，2=2/28/2009 11:00:00 PM
完：2012年2月28日下午11:00:00，2012年2月29日下午11:00:00

注意我所做的变量

ToUniversalTime（）.AddYears（3）。ToLocalTime（）

不同于

AddYears（3）

，它提前了一天

有人遇到过这种情况吗？如果这是意料之中的，有人能解释一下背后的逻辑吗

---

注意：是的，最好的方法是完全在UTC中工作，而不是在它们之间切换。这不是影响我的东西，而是我遇到的一个怪癖。基本上，我误解了

AddYears（）

的工作原理，现在我明白了它为什么要这么做了（参见下面我选择的答案）。

打印时区/校正系数。当您执行.touniversisaltime（）时，它实际上是将原始时间的8小时（“08:00”）相加，即从2月28日23:00开始的第二天11:00。所以当你再加上3年的时候，是29日上午11点。如果你做了两年，那就是3月1日，这与闰年无关。

我认为这是正确的

DateTime dtStartUtc = dtStartLocal.ToUniversalTime();

PST是UTC-8。因此，这会将时间转换为2009年3月1日07:00:00

DateTime dtEndUtc = dtStartUtc.AddYears(3);

DateTime dtEndLocal2 = dtEndUtc.ToLocalTime();

这比上一次增加了三年，即2012年3月1日07:00:00

DateTime dtEndUtc = dtStartUtc.AddYears(3);

DateTime dtEndLocal2 = dtEndUtc.ToLocalTime();

这会将结束时间转换回PST，即2012年2月29日11:00:00

---

我想说这只是在本地时间和UTC时间之间转换的副作用。

据我所知，这种行为并不错误。当您将本地时间转换为UTC时，它会有效地将其推到第二天；三月一日。当你加上三年，它保持为3月1日。将它转换回当地时间，它会回滚到前一天，因为2012年是闰年，所以是2月29日。

很好的解释。这是一个很好的例子，说明了为什么应该使用UTC日期时间进行日期计算。不，这是一个很好的例子，说明了为什么在不同的时区进行日期计算是不好的。您可以在当地时间执行每项操作，但仍然会得到与UTC相同的结果。只要你是一致的，这没关系。@Whatsit:在这种情况下是的，但如果我们在组合中加入DST，UTC是唯一合理的方法谢谢，看来我误解了AddYears（）的工作原理。这是有道理的，它只是减少了一年的财产，但我认为它工作了一年的长度。我真傻。。。