6

我们看到 .NET 4.5 和 System.DateTime 的奇怪行为。与 .NET 4.0 相比，在具有 .NET 4.5 的 Server 2008R2 机器上，ToLocalTime() 应用于 Kind=Utc 的 DateTime 对象时的行为似乎有所不同。更奇怪的是，安装了 .NET 4.5 的开发人员 PC 上并未出现此问题。

有人对这种行为有解释吗？我无法在 Microsoft 网站上找到任何错误报告。我们可以使用更复杂的方法来转换有效的时间，但很难确保将来没有人使用 .ToLocalTime() 。

开发人员 PC - 在 VS2012 安装期间安装的 Windows 7、VS2012、.NET 4.5：

unixEpoch 621355968000000000 Utc 
asLocal1 635121441023588986 Local 
asLocal2 635121441023588986 Unspecified

生产服务器 1 - 服务器 2008R2，.NET 4.0

unixEpoch 621355968000000000 Utc 
asLocal1 635121441023588986 Local 
asLocal2 635121441023588986 Unspecified

生产服务器 2 - Server 2008R2，.NET 4.5 作为独立包安装

unixEpoch 621355968000000000 Utc
asLocal1 ***635121405023588986*** Local
asLocal2 635121441023588986 Unspecified

除了安装 .NET 4.5 之外，生产服务器 1 和 2 是相同的。当在全球多个不同的本地时区运行时，问题就会显现出来。

演示问题的示例代码：

using System;
using NUnit.Framework;
namespace DateTimeToLocal
{
   [TestFixture]
   public class DateTimeFixture
   {
      private const long unixTimeInNanos = 1376561702358898611;

      [Test]
      public void Demonstrate()
      {
         DateTime unixEpoch = new DateTime(1970, 01, 01, 0, 0, 0, DateTimeKind.Utc);
         DateTime utc = unixEpoch.AddTicks(unixTimeInNanos / 100);

         // Method 1 - doesn't work on 2008R2 with .NET 4.5
         DateTime asLocal1 = utc.ToLocalTime();

         // Method 2 - works across all .NET 4.0 and .NET 4.5
         TimeZoneInfo localTz = TimeZoneInfo.FindSystemTimeZoneById(TimeZoneInfo.Local.StandardName);
         DateTime asLocal2 = TimeZoneInfo.ConvertTimeFromUtc(utc, localTz);

         Console.WriteLine("unixEpoch {0} {1}", unixEpoch.Ticks,unixEpoch.Kind);
         Console.WriteLine("asLocal1 {0} {1}", asLocal1.Ticks, asLocal1.Kind);
         Console.WriteLine("asLocal2 {0} {1}", asLocal2.Ticks, asLocal2.Kind);

         Assert.AreEqual(asLocal1, asLocal2);
      }

      public static void Main(string[] args)
      {
         var t = new DateTimeFixture();
         t.Demonstrate();

      }
   }
}
4

1 回答 1

2

将以下修补程序应用于运行 2008R2 的服务器后，此问题就会消失：http: //support.microsoft.com/kb/2863058/en-us

似乎在幕后， DateTime.ToLocalTime() 使用了一种查找技术，除非已应用该修补程序中包含的时区数据库更新，否则该技术会失败。

这很难追踪，而且我还没有看到任何其他网络论坛提到该数据库更新与 utc.ToLocalTime() 等基本内容之间的联系，因为 utc.ToLocalTime() 在 2013 年 8 月的日期失败，离最近的边界变化不远了由于美国东部的立法等原因仍然想知道这到底是怎么没有被更多的地方看到？

于 2013-08-27T16:21:53.903 回答