.Net TimeZoneInfo.GetUtcOffset 是如何工作的？
How does .Net TimeZoneInfo.GetUtcOffset work?
我正在 https://docs.microsoft.com/en-us/dotnet/api/system.timezoneinfo.getutcoffset?view=netframework-4.8 阅读 TimeZoneInfo.GetUtcOffset 的文档，我有点困惑。该文件指出此方法
Calculates the offset or difference between the time in this time zone and Coordinated Universal Time (UTC) for a particular date and time.
但据我了解，对于特定的时间，不同时区的人使用不同的数字来表示。如果我在日本使用时区 UTC+9，而 Michael 在某个地方使用 UTC。我在 Skype 上与他交谈，我们的当地时间不同。我的当地时间和迈克尔的当地时间总是有完全相同的差异。如果我的当地时间是 10:00 am，他的是 1:00 am。如果我的是 10:01 am，他的是 1:01 am。区别是一样的，只能通过我的时区和他的时区来确定，时间本身是不相关的。
所以 TimeZoneInfo.GetUtcOffset 正在计算此时区的时间与特定日期和时间 的协调世界时 (UTC) 之间的差异 。看起来它和我前面提到的例子一样。我的当地时间是上午 10:00，我的当地时间和 Michael 的时间有什么区别？这里不需要时间。为什么该方法采用 DateTime 或 DateTimeOffset 参数？
几件事：
时区不仅仅是一个数字偏移量。许多时区会定期更改其偏移量，例如当美国太平洋时间在 UTC-8 (PST) 和 UTC-7 (PDT) 之间转换 daylight saving time. Additionally, several time zones have had changes to their standard time, such as when Venezuela switched from UTC-4:30 to UTC-4 in 2016. For more on this, read "Time Zone != Offset" in the timezone tag wiki.
一个TimeZoneInfo对象表示一个时区的完整状态集，包括它使用或可能使用的所有偏移量。 （至少从 2010 年开始 Windows，至少从 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 以开始夏令时。相反，2019-11-03T01:30:00 在太平洋时间存在 两次 ，因为时钟从 01:59:59 移回到 01:00:00 以作为 DST 的结束。请注意，在这种情况下，TimeZoneInfo 对象的方法将始终推断出 标准时间 ，这可能适合也可能不适合您的场景。在许多情况下，夏令时是首选。
在您的示例中，请注意迈克尔通常不会是 "somewhere using UTC"。对于给定的时间点，本地时区始终使用 UTC 的 offsets 表示。有时该偏移量为零。例如，伦敦在标准时间期间使用 GMT (UTC+0)，在夏令时期间使用 BST (UTC+1)（又名 "summer time"）。如果 Michael 在伦敦，那么了解 BST 是否生效就很重要。
请注意，从技术上讲，UTC 并不是 "time zone"，而是一种计时标准。它出现在可用时区列表中，因为有时需要一台计算机只跟踪 UTC 时间。这是服务器的最佳做法，但对于本地计算机或设备并不常见。
即使在日本，UTC+9 也不总是偏移量。日本以前使用 UTC+10，最后一次是 1951 年。由于年代久远，此详细信息不在 Windows 时区数据中，但在其他平台上本地使用的 IANA 时区数据中确实存在，并且在 . NET 通过 Noda Time.
我正在 https://docs.microsoft.com/en-us/dotnet/api/system.timezoneinfo.getutcoffset?view=netframework-4.8 阅读 TimeZoneInfo.GetUtcOffset 的文档，我有点困惑。该文件指出此方法
Calculates the offset or difference between the time in this time zone and Coordinated Universal Time (UTC) for a particular date and time.
但据我了解，对于特定的时间，不同时区的人使用不同的数字来表示。如果我在日本使用时区 UTC+9，而 Michael 在某个地方使用 UTC。我在 Skype 上与他交谈，我们的当地时间不同。我的当地时间和迈克尔的当地时间总是有完全相同的差异。如果我的当地时间是 10:00 am，他的是 1:00 am。如果我的是 10:01 am，他的是 1:01 am。区别是一样的，只能通过我的时区和他的时区来确定，时间本身是不相关的。
所以 TimeZoneInfo.GetUtcOffset 正在计算此时区的时间与特定日期和时间 的协调世界时 (UTC) 之间的差异 。看起来它和我前面提到的例子一样。我的当地时间是上午 10:00，我的当地时间和 Michael 的时间有什么区别？这里不需要时间。为什么该方法采用 DateTime 或 DateTimeOffset 参数？
几件事：
时区不仅仅是一个数字偏移量。许多时区会定期更改其偏移量，例如当美国太平洋时间在 UTC-8 (PST) 和 UTC-7 (PDT) 之间转换 daylight saving time. Additionally, several time zones have had changes to their standard time, such as when Venezuela switched from UTC-4:30 to UTC-4 in 2016. For more on this, read "Time Zone != Offset" in the timezone tag wiki.
一个
TimeZoneInfo对象表示一个时区的完整状态集，包括它使用或可能使用的所有偏移量。 （至少从 2010 年开始 Windows，至少从 1970 年开始在其他平台上。）- 旁注：尽量不要过多解读 Windows 中使用的标识符的名称。有很多令人困惑的命名约定，例如
"Pacific Standard Time"是涵盖 PST 和 PDT 的 ID。 the timezone tag wiki. 中列出了更多示例
- 旁注：尽量不要过多解读 Windows 中使用的标识符的名称。有很多令人困惑的命名约定，例如
因此，要知道想要从
GetUtcOffset返回哪个偏移量，必须提供一个时间点，最好使用DateTimeOffset对象，因为它代表一个不同的点及时。- 如果您改为提供
DateTime对象，那么它的Kind属性 很重要。如果它是DateTimeKind.Local或DateTimeKind.Utc那么您引用的时间点是不同的。但是，如果它是DateTimeKind.Unspecified，则该值可能不明确或无效。例如，2019-03-10T02:30:00在美国太平洋时间不存在，因为时钟从 1:59:59 前进到 03:00:00 以开始夏令时。相反，2019-11-03T01:30:00在太平洋时间存在 两次 ，因为时钟从 01:59:59 移回到 01:00:00 以作为 DST 的结束。请注意，在这种情况下，TimeZoneInfo对象的方法将始终推断出 标准时间 ，这可能适合也可能不适合您的场景。在许多情况下，夏令时是首选。
- 如果您改为提供
在您的示例中，请注意迈克尔通常不会是 "somewhere using UTC"。对于给定的时间点，本地时区始终使用 UTC 的 offsets 表示。有时该偏移量为零。例如，伦敦在标准时间期间使用 GMT (UTC+0)，在夏令时期间使用 BST (UTC+1)（又名 "summer time"）。如果 Michael 在伦敦，那么了解 BST 是否生效就很重要。
请注意，从技术上讲，UTC 并不是 "time zone"，而是一种计时标准。它出现在可用时区列表中，因为有时需要一台计算机只跟踪 UTC 时间。这是服务器的最佳做法，但对于本地计算机或设备并不常见。
即使在日本，UTC+9 也不总是偏移量。日本以前使用 UTC+10，最后一次是 1951 年。由于年代久远，此详细信息不在 Windows 时区数据中，但在其他平台上本地使用的 IANA 时区数据中确实存在，并且在 . NET 通过 Noda Time.
中的 TZDB 提供程序