【问题标题】：How does .Net TimeZoneInfo.GetUtcOffset work?.Net TimeZoneInfo.GetUtcOffset 如何工作？
【发布时间】：2019-12-01 10:59:37
【问题描述】：
我正在阅读TimeZoneInfo.GetUtcOffsethttps://docs.microsoft.com/en-us/dotnet/api/system.timezoneinfo.getutcoffset?view=netframework-4.8 的文档，我有点困惑。文档说明这种方法
计算该时区的时间与特定日期和时间的协调世界时 (UTC) 之间的偏移或差异。
但据我了解，在特定时间，不同时区的人使用不同的数字来表示他们。如果我在日本使用时区 UTC+9，而迈克尔在某处使用 UTC。我在 Skype 上与他交谈，我们有不同的当地时间。我的当地时间和迈克尔的当地时间总是有完全相同的差异。如果我的当地时间是上午 10:00，他的时间是上午 1:00。如果我的时间是上午 10:01，那么他的时间是上午 1:01。区别是一样的，只能由我的时区和他的时区来确定，时间本身不相关。
所以TimeZoneInfo.GetUtcOffset 正在计算该时区的时间与特定日期和时间的协调世界时 (UTC) 之间的差异。看起来和我前面提到的例子一样。我的当地时间是上午 10:00，我的当地时间和迈克尔的时间有什么不同？这里不需要时间。为什么该方法需要DateTime 或DateTimeOffset 参数？
【问题讨论】：
标签：
.net
datetime
timezone
utc
【解决方案1】：
一些事情：
时区不仅仅是一个数字偏移量。许多时区定期更改它们的偏移量，例如当美国太平洋时间在 UTC-8 (PST) 和 UTC-7 (PDT) 之间转换时，daylight saving time。此外，几个时区的标准时间发生了变化，例如委内瑞拉在 2016 年从 UTC-4:30 切换到 UTC-4。有关更多信息，请阅读“时区！= 偏移量" 在the timezone tag wiki。
-
TimeZoneInfo 对象表示时区的完整状态集，包括它使用或可能已经使用的所有偏移量。 （在 Windows 上至少从 2010 年开始，在其他平台上至少从 1970 年开始。）
- 旁注：尽量不要过多解读 Windows 中使用的标识符名称。有很多令人困惑的命名约定，例如
"Pacific Standard Time" 是同时涵盖 PST 和 PDT 的 ID。 the timezone tag wiki 中列出了更多示例。
-
因此，要知道想要从GetUtcOffset 返回哪个偏移量，必须提供一个时间点，最好使用DateTimeOffset 对象，因为它代表一个不同的时间点。
- 如果您改为提供
DateTime 对象，则其Kind 属性很重要。如果是DateTimeKind.Local 或DateTimeKind.Utc，那么您引用的时间点是不同的。但是，如果它是 DateTimeKind.Unspecified，则该值可能会模棱两可或无效。例如，2019-03-10T02:30:00 在美国太平洋时间不存在，因为时钟从 1:59:59 提前到 03:00:00 为 DST 开始。相反，2019-11-03T01:30:00 在太平洋时间存在 两次，因为在 DST 结束时时钟从 01:59:59 向后移动到 01:00:00。请注意，在这种情况下，TimeZoneInfo 对象的方法将始终推断标准时间，这可能适合您的场景，也可能不适合您的场景。在许多情况下，首选白天时间。
-
在您的示例中，请注意迈克尔通常不会“在某处使用 UTC”。对于给定的时间点，本地时区始终使用 UTC 的 偏移量 表示。有时该偏移量为零。例如，伦敦在标准时间使用 GMT (UTC+0)，在夏令时（又称“夏令时”）使用 BST (UTC+1)。如果迈克尔在伦敦，那么了解 BST 是否有效就很重要。
请注意，UTC 在技术上不是“时区”，而是计时标准。它出现在可用时区列表中，因为有时需要一台计算机以 UTC 跟踪时间。这是服务器的最佳做法，但不适用于本地计算机或设备。
即使在日本，UTC+9 也并非始终是偏移量。日本以前使用 UTC+10，最后一次是在 1951 年。由于其年代久远，此详细信息不在 Windows 时区数据中，但确实存在于其他平台上本地使用的 IANA 时区数据中，并且可通过 TZDB 在 .NET 中获得Noda Time 中的提供者。