为什么 TimeZoneInfo.DisplayName 中的 UTC 偏移量不会因为夏令时而改变？

Question

这个问题与 Windows 时区数据库中使用的标题有关，而不是实际转换时间，其中有许多类似标题的问题 - 请标记是否重复，我将删除它）。

上周我创建了一个快速输出测试来了解 .Net Framework (4.8.1)

TimeZoneInfo

类以及

GetSystemTimeZones()

中的属性值。

上周末，欧洲许多国家已切换为英国夏令时/夏令时。鉴于这一变化，今天同样的迭代......

var zones = TimeZoneInfo.GetSystemTimeZones().OrderBy(z => z.Id);
foreach (TimeZoneInfo zone in zones)
{
    Console.WriteLine(zone.Id);
    Console.WriteLine(" " + zone.DisplayName);
    Console.WriteLine(" " + zone.DaylightName);
    Console.WriteLine();
}

...现在产生的结果与上周略有不同：

GMT Standard Time
 (UTC+00:00) Dublin, Edinburgh, Lisbon, London
 GMT Summer Time

我注意到在我的输出中，

TimeZoneInfo.DaylightName

已相应切换为GMT夏令时间（我实际上不记得上周说了什么，但我认为这是GMT标准时间），但我的困惑是为什么

(UTC+00:00) Dublin, Edinburgh, Lisbon, London

还没有成为

(UTC+00:01) Dublin, Edinburgh, Lisbon, London

考虑到调整后的 BST 偏移量？

我正在尝试为我的用户界面创建一个时区选择器，但担心

TimeZoneInfo.DisplayName

使用的标题可能会令人困惑。

Answer 1

欢迎来到令人困惑的 Windows 时区世界。有很多事情并不完全有意义。其中一些，包括显示名称中的偏移量，在 Stack Overflow 上标题为“时区数据库”的部分中的时区标签 wiki 中提到。这很大程度上与 Windows NT 早期的设计选择有关，并且今天仍然是 Windows 11 的一部分。

需要明确的是，这不是 .NET 问题，而是 Windows 问题。一种设计影响了另一种设计。您在 Windows 上运行 .NET Framework，因此在使用

TimeZoneInfo

时您将看到 Windows 标识符和显示名称。但是，如果您在 Linux 或 macOS 上运行 .NET 6 或更高版本，您会看到来自 IANA 的标识符和源自 Unicode CLDR 的显示名称。

特别是关于在 Windows 上运行时显示名称中的偏移量的问题：

• 整个

  DisplayName

  字符串（包括偏移量）存储为 Windows 资源字符串。它按操作系统语言进行本地化，并通过 Windows 语言包和 Windows 更新进行更新。
• 偏移量是对应于

  TimeZoneInfo.BaseUtcOffset

  的值。
• 它不会因 DST 而改变，但如果时区的 standard 偏移量已更改，则在应用 Windows 更新时可能会发生变化。
• 它并不旨在表示 current 偏移量，而是用户可能认为的当前 standard 偏移量。例如，

  -08:00

  表示太平洋时间，无论 PST 或 PDT 是否有效。
• 显示名称中包含偏移量的主要原因是为了在列表中显示时按顺序对它们进行排序。如果没有偏移量，可能很难找到特定的时区。
  • 如果偏移量是动态的，表示“当前”偏移量，则列表中的值（以及排序顺序）每次出现时可能会有所不同。 选择时区通常与选择事件的日期/时间相关。无法保证列表中的偏移量在事件日期上是正确的，无论偏移量是静态的还是与当前时间动态关联的。相反，它们必须与事件的日期/时间相关联，这将需要新的 API 来根据特定日期/时间生成列表。
其他几点：

英国夏令时期间英格兰的偏移量是

+01:00
• ，而不是

  +00:01

  与
DisplayName
• 一起，

  StandardName

  和

  DaylightName

  属性也按语言进行本地化 - 使用 Windows 上的操作系统语言。 （

  Id

  属性

  未

  本地化。） 在 Windows 上，
Id
• 、

  StandardName

  和

  DaylightName

  属性的实际值通常是虚构的，有时会令人困惑。恕我直言，其中一些完全是垃圾。如果您能提供帮助，我会避免向用户展示它们。您可能会发现我的
TimeZoneNames
• 库对于解决您的一些问题很有用，但您仍然需要仔细考虑您希望应用程序具有什么行为。