.NET DateTime.ToLocalTime 是否在 DST 更改中持续存在？答案

【问题标题】：Does .NET DateTime.ToLocalTime persist across DST changes?.NET DateTime.ToLocalTime 是否在 DST 更改中持续存在？
【发布时间】：2016-02-05 07:11:30
【问题描述】：

在英国，时钟于 2015 年 10 月 25 日更改

如果我在 2015 年 10 月 24 日和 2015 年 10 月 26 日再次运行以下代码，会产生相同的输出吗？

根据我对 DateTime 在 C# 中的工作原理的了解，我假设是的，但我想仔细检查一下，因为它对我的应用程序至关重要。

// January date outside of DST
var januaryDate = new DateTime(2015, 1, 1, 0, 0, 0, DateTimeKind.Utc);
Console.WriteLine(januaryDate.ToLocalTime().ToString());

// April date inside DST
var aprilDate = new DateTime(2015, 4, 1, 0, 0, 0, DateTimeKind.Utc);
Console.WriteLine(aprilDate.ToLocalTime().ToString());

【问题讨论】：

当地时间意味着您的当前时区。甚至同一台机器上的不同用户也可能使用不同的时区。如果您关心偏移量，请使用 DateTimeOffset，而不是 DateTime。如果它很重要（例如在航空旅行中），请检查 NodaTime - 它包含最新的 IANA 时区数据库，因此您不必猜测 BST 意味着（巴西或英国）或达拉斯的正确偏移量是什么跨度>
@PanagiotisKanavos 谢谢，但不幸的是我坚持使用 DateTime 类型。假设这个问题是同一台机器上的同一个用户。
那你就麻烦了。至少，指定日期类型（即本地或 UTC），因为现在它是未指定的并被视为 UTC。 ToLocalTime() 在我的机器上应用了 2 小时的偏移量，即 +2:00。猜猜这也回答了您的问题，但也说明了您遇到麻烦的原因。除非您确保偏移量或种类与您的日期一起存储（即在数据库、文件等中）并在处理之前正确设置，否则您可能会得到意想不到的结果
例如，从数据库加载的日期时间是 Unpsecified。 SQL Server 和其他数据库确实支持带偏移量的类型，但如果您打算将它们用作DateTime，您仍然会面临转换。
ToLocalTime 使用当前时区的调整规则来确定在指定 DateTime 值处有效的偏移量，而不是在当前时间有效的偏移量。所以不，他们不应该在不同的日子里给出不同的答案。但是请注意，在较旧的系统上，实际上并没有调整规则随时间变化的概念。这就是为什么文档对在 XP 系统上使用此方法发出警告的原因。

标签： c# .net datetime timezone dst

【解决方案1】：

ToLocalTime 使用当前时区的规则，而不仅仅是当前偏移量来计算本地时间。在 2015-01-01 00:00 和 2015-04-01 00:00 上调用 ToLocalTime 将返回相同的结果，无论调用是在 DST 更改之前还是之后进行的。

我当前的偏移量是+2，但调用示例代码在第一种情况下返回1/1/2015 2:00:00 am，在第二种情况下返回1/4/2015 3:00:00 am。

查看ToLocalTime的引用来源表明该方法在返回本地时间之前检查是否需要为特定日期申请DST：

Boolean isDaylightSavings = false;
Boolean isAmbiguousLocalDst = false;
Int64 offset = TimeZoneInfo.GetUtcOffsetFromUtc(this, TimeZoneInfo.Local,
                           out isDaylightSavings, out isAmbiguousLocalDst).Ticks;

long tick = Ticks + offset;
//various validations
//...
return new DateTime(tick, DateTimeKind.Local, isAmbiguousLocalDst);

【讨论】：

不错的一个！这对我有很大帮助，希望对其他人也有帮助