使用 TimeZoneInfo.ConvertTime() 的时间不正确

Question

转换自以下位置时，我遇到了意外的日期时间：

(UTC) Dublin, Edinburgh, Lisbon, London到(UTC-08:00) Baja California

下面是我一直在使用的代码。 我预计serverDateTime会29/03/2016 00:00:01(-8 小时(，但我得到了28/03/2016 23:00:01 - 这是 9 小时的差异。

    private static void Main(string[] args)
    {
        ReadOnlyCollection<TimeZoneInfo> timeZones = TimeZoneInfo.GetSystemTimeZones();
        TimeZoneInfo localTimeZone = timeZones.FirstOrDefault(tz => tz.DisplayName.Contains("London"));
        TimeZoneInfo serverTimeZone = timeZones.FirstOrDefault(tz => tz.DisplayName.Contains("California"));
        DateTime clientDateTime = new DateTime(DateTime.Now.Year, DateTime.Now.Month, 29, 8, 0, 1);
        DateTime serverDateTime = TimeZoneInfo.ConvertTime(clientDateTime, localTimeZone, serverTimeZone);
    }

我的本地机器在英国，目前是 UTC+1，而下加利福尼亚州目前是 UTC-7，所以我预计会得到 8 小时的差异，而不是 9 小时。 我做错了什么？

提前谢谢。

Answer 1

几件事：

• "(UTC-08:00) Baja California"指的是墨西哥的下加利福尼亚州 - 而不是美国加利福尼亚州。
• 此区域条目遵循墨西哥 DST 规则，该规则直到今年 4 月 3 日才开始 DST。 因此，此条目仍在UTC-8上，解释了您观察到的时差。

• 这个特定的条目在Windows中实际上是错误的，因为事实证明，整个下加利福尼亚州都遵循美国夏令时规则，而不是墨西哥规则。

  • 在 2015 年 10 月和 11 月的 tz 邮件列表存档中对此进行了广泛的多线程讨论。 这导致相应的 IANA 区域America/Santa_Isabel在 2016a 版本中被弃用。 它现在链接到America/Tijuana，它已经遵循美国夏令时规则。
  • Microsoft尚未对其数据进行类似的更改，但可能会在未来更新Windows时区数据。 (我已经将此传达给适当的人员。 同时，请使用"(UTC-08:00) Pacific Time (US & Canada)" - 即使您谈论的是墨西哥下加利福尼亚州。

• 不要试图按时区DisplayName查找时区。 这些值将根据操作系统语言而有所不同。 请改用 TimeZoneInfo.FindSystemTimeZoneById 。 Id属性未本地化。 此外，Microsoft认为Id值是稳定的标识符，因此它们不会随着将来的更新而更改。 DisplayName值在过去已被修改，将来确实可能会更改。

  • 将 ID "GMT Standard Time"用于"(UTC) Dublin, Edinburgh, Lisbon, London"
  • 将 ID "Pacific Standard Time"用于"(UTC-08:00) Pacific Time (US & Canada)"
  • ID "Pacific Standard Time (Mexico)"用于"(UTC-08:00) Baja California" - 但出于我描述的原因，请勿使用此条目。

• 真的，您根本不应该关心服务器上的时区。 服务器应该只关注 UTC。 (请注意，伦敦不是UTC，因为它在夏天切换到BST(

• 我不确定你对这行的意图是什么：

  DateTime clientDateTime = new DateTime(DateTime.Now.Year, DateTime.Now.Month, 29, 8, 0, 1);
  

  从DateTime.Now中提取月份和年份将使用服务器的时区。 然后，您将固定的29日和8:00:01的固定时间结合起来。 这将在非闰年的 2 月(当月只有 28 天时(失败，并且当服务器的日期与客户端的日期不在同一月份和年份时(例如接近从一个月到另一个月的转换(，也可能给出错误的日期。