c# - TimeZoneInfo.ConvertTime 在 DateTime.MinValue 上非常慢

Question

我刚刚注意到我们的一个单元测试占用了 10 秒。在玩弄它之后，我创建了一个最小的 linqpad 示例来重现它:

void Main()
{
    Stopwatch sw = new Stopwatch();
    sw.Start();
    var timeZone = TimeZoneInfo.Local;
    for(int i=0; i<10000; i++)
    {
      //var dateTime = TimeZoneInfo.ConvertTime(DateTime.UtcNow, timeZone);   
      var dateTime = TimeZoneInfo.ConvertTime(DateTime.MinValue, timeZone);   
    }
    sw.Stop();
    (sw.ElapsedMilliseconds + " ms").Dump();
}

这在我的 PC 或我们的构建 PC 上需要 40 秒。如果我使用 DateTime.UtcNow，则需要 15 毫秒。

有什么原因或解决方法吗？

---

编辑:按照评论中的建议，我反编译了 TimeZoneInfo 并且 DateTime.MinValue 有一个特例:

static public DateTime ConvertTime(DateTime dateTime, TimeZoneInfo destinationTimeZone) {
    // Special case to give a way clearing the cache without exposing ClearCachedData()
    if (dateTime.Ticks == 0) {
        ClearCachedData();
    }

看起来(测试？)代码每次使用 DateTime.MinValue 调用时都会清除缓存。

留下为什么会这样的问题。

Answer 1

不需要反编译。您可以在 the .NET Framework Reference Source 中找到它，或在 the CoreCLR source code on GitHub .

这种特殊情况是在 .NET 4.6 中添加的，作为一种非官方的解决方法，用于在 WinRT 等当时没有公开 ClearCachedData 方法的环境中清除时区缓存。 I describe this further here .

偶尔清除时区缓存通常不会产生明显的影响。你看到它是因为紧密的循环。如果这对您的用例来说是一个问题，那么我建议使用 ConvertTimeFromUtc 方法，或者使用 DateTimeOffset 的 ConvertTime 版本。这些代码路径不符合特殊情况。

是的，我同意应该更好地记录这一点。我看看能不能把它放进去。

请注意，从逻辑上讲，为 DateTime.MinValue 转换时区没有太大意义，因为我们今天所知道的时区在第 1 年不存在。