关于c＃：在.NET中调整“夏令时”（DST）选项，就像Windows一样


Adjust “Daylight Saving Time” (DST) option in .NET, just like Windows

我尝试在UWP应用程序中复制Windows日期和时间设置，但在处理夏令时(DST)设置时遇到了问题。

我设法让一切正常运行，我可以从我的应用程序更改系统时间和时区，但自动调整夏令时的选项让我困惑。

起初，我认为检查TimeZoneInfo.SupportsDaylightSavingTime就足够了，然后我发现我可能还需要通过执行TimeZoneInfo.IsDaylightSavingTime检查当前选择的日期/时间是否在DST范围内。

嗯，我认为我做得对，但是测试后，我自己的"调整DST"选项与Windows设置不同，因为我看不到Windows源代码，所以我不知道他们正在检查哪些其他条件来禁用/启用它。

我的UWP应用程序：

Date & Time settings in my UWP app

Windows设置：

Windows Date & Time settings

我还缺什么吗？关于这一点，我的另一个问题可以在这里为感兴趣的人找到。

也许一些有内幕信息的微软开发者可以告诉我这个切换开关背后的逻辑：—)

提前谢谢！

更新：

TZUTIL的结果显示，当日期为2011年5月16日，时区为莫斯科(UTC+3)时，使用命令tzutil /s"Russian Standard Time_dstoff"关闭DST，只返回"俄罗斯标准时间"，而不返回DST，因为DST不适用，这与Windows报告一致。

但是，为什么.NET的TimeZoneInfo类会这样说呢？.NET says current datetime is in DST range也尝试使用：

1
2
var currentDateTime = new DateTime(2011, 5, 16, 0, 0, 0, DateTimeKind.Local);
var isDst = TimeZoneInfo.Local.IsDaylightSavingTime(currentDateTime); //True

所以，.NET说当前日期在DST范围内，但是不能使用TZUTIL或Windows设置关闭DST？

也许我错过了一些显而易见的东西，但我看不到…

更新：

将月份改为二月，在窗口中打开调整DST开关，是否符合调整规则？但是，在赫尔辛基，我们也有这些转换，并且切换没有被禁用？有什么不同？

更新：

决定不这样做，只需检查TimeZoneInfo.SupportsDaylightSavingTime。任何人的时间和精力都不值得像Windows那样做。

有几个问题需要解决：好的。

  • 永远不要使用System.TimeZone类。它有很多问题，还有更好的选择。对于大多数.NET代码，使用System.TimeZoneInfo代替。既然您说您正在编写一个uwp应用程序，那么您还可以从Windows.Globalization.Calendar和Windows.Globalization.DateTimeFormatting.DateTimeFormatter类中获益。开放源码库如noda time也可以是一个不错的选择。好的。

    在您展示的第一个代码块中，您使用的是System.TimeZone.IsDaylightSavingTime。文档中的注释解释了您看到的结果：好的。

    "Because the TimeZone class supports a single daylight saving time adjustment rule, the IsDaylightSavingTime(DateTime) method applies the current adjustment rule to any date, regardless of whether the adjustment rule was in effect on that date. Assuming that the operating system itself has accurate historic daylight saving time data, a more accurate result is available by using the TimeZoneInfo.IsDaylightSavingTime method. Whenever possible, use the TimeZoneInfo.IsDaylightSavingTime method."

    Ok.

  • 在您展示的第二个代码块中，您正确地使用了System.TimeZoneInfo.IsDaylightSavingTime，并且在预期False时得到了True。虽然这令人困惑，而且可能不正确，但可以解释为：好的。

    • 2011年，莫斯科在UTC+3开始了日历年。然后在3月27日凌晨2:00将其偏移量更改为UTC+4(此处参考)。这是标准时间的变化，而不是与DST相关的变化。
    • Windows中的数据结构(TIME_ZONE_INFORMATION、DYNAMIC_TIME_ZONE_INFORMATION，更具体地说，REG_TZI_FORMAT不支持日历年中标准偏移量的更改。他们的设计思想没有这种变化-很久以前。
    • 为了适应当地时间的变化，在Windows中将其建模为DST变化，其中DST周期从3月27日凌晨2:00开始，一直持续到年底。这使得本地时间在转换过程中保持准确，而代价是从API返回不准确的信息，这些信息说明或推断它们的结果与DST(如System.TimeZoneInfo.IsDaylightSavingTime)显式相关。
    • 因此，可以考虑这样的方法，告诉您某个时段的本地时间与UTC的偏移量是否高于一年中的某个其他时间点。它可能与DST有关，也可能与标准时间的变化有关。

  • 据我所知，Windows确实会查看这些数据来确定是否显示选项。如果当前日历年中存在过渡(由系统时钟确定)，则将显示选项-无论此过渡是与DST相关还是由于其他原因。好的。

此外，一些一般性建议：好的。

  • 大多数应用程序不应尝试更改系统时间、时区或DST设置。虽然确实有办法做到这一点，但它可能会产生巨大的后果。这些是系统范围的全局设置，将影响计算机上的所有内容，而不仅仅是应用程序。好的。

    特别是，过于剧烈地改变时间可能会影响到与其他系统进行正确身份验证的能力。例如，Windows身份验证(Active Directory、SSPI等)使用的是kerberos，它与UTC的公差为5分钟。此外，根据系统时钟，如果证书过期或尚未颁发，则访问使用安全证书(https、ssl、tls等)的网站可能会失败。因此，最安全的成功途径是自动设置时间，而不允许用户偏离。好的。

    虽然更改时区和/或DST设置不会影响AUTH，但它仍然是全局设置。使用本地时间工作的机器上的任何地方都将使用此设置，而不仅仅是您的应用程序。好的。

  • 如果您确实要更改时区，请记住，您可能需要清除本地时区缓存以获取应用程序中的新设置。有关详细信息，请参阅此问题和答案。好的。

  • 如果您的目的只是为了更改应用程序的时区，那么只需跟踪所选时区的TimeZoneInfo.Id，并在需要时通过TimeZoneInfo.ConvertTime和相关方法应用它。好的。

  • 您可能不需要设置来禁用自动DST调整。此设置在Windows中的存在，是早期Winnt和Win9x时区设置的原始实现的遗留项目。大多数用户应将其保留为打开状态。好的。

    这些天，关闭它只有一个合法的使用案例，即当政府宣布时区从一个有DST的更改为一个没有DST(或有"永久DST")的更改，并且没有DST，没有其他现有的时区条目具有相同的基准偏移，并且该政府没有为micros提供足够的时间时。在变更生效之前，经常为受影响的区域创建和分发一个新的时区条目。这样的事情确实发生了，但很少发生。天哪，这种设置在将来某个时候消失是合理的。(只是我个人的意见，不代表微软谈这个。)好的。

好啊。

相关讨论