TimeZoneInfo Id依赖于计算机

虽然可能找不到ID（请参阅其他答案），但如果两台机器都有当前的Windows更新，则不太可能出现不匹配。

即便如此，尽管夏令时和显示名称的定义每年都会发生多次更改，但很少会创建全新的时区，ID一旦建立就永远不会更改。

因此，只要您的服务器具有当前时区的Windows更新，那么您就应该能够处理来自客户端的任何有效输入，即使它们不是最新的。您可以查看此网站上Windows的所有时区更新。

然而，尽管如此，我最好的建议是放弃使用微软时区，转而使用标准的IANA时区。有关详细信息，请参阅时区标记wiki。在.NET中，实现这一点的最佳方法是使用Noda Time库。

TimeZone的东西总是让我困惑，但我的答案是是。有可能在不同的服务器上不起作用。

TimeZoneInfo.FindSystemTimeZoneById()方法使用HKEY_LOCAL_MACHINE'Software'Microsoft'Windows NT'CurrentVersion'Time Zones注册表信息。有时微软会发布一些windows更新来更改这些信息。

例如，2012年8月Windows操作系统的累计时区更新；

• E。欧洲标准时间：此时区的显示名称已从"（UTC+2:00）尼科西亚"更新为"（UT0+2:00）欧洲东部"
• 亚速尔群岛标准时间：将2013夏令时开始时间更改为3月最后一个星期日凌晨12:00:00，结束时间更改为十月最后一个星期日凌晨01:00:00
• 太平洋SA标准时间：如微软知识库文章2681116所述，智利延长了2012年夏令时节省时间。智利政府改变了2012年夏令时的开始时间日期发生在9月的第一个星期六23:59:59.999并结束日期为4月最后一个星期六23:59:59.999

正如您所看到的，您的一个服务器的注册表中没有相同的信息（例如，一个服务器无法更新），这些TimeZone信息看起来不同。

根据MSDN-TimeZoneInfo.FindSystemTimeZoneById方法，如果找不到Id，您将获得TimeZoneNotFoundException。

找不到id指定的时区标识符。这意味着名称与id匹配的注册表项不存在，或者键存在，但不包含任何时区数据。

因为您只需要将服务器日期时间转换为本地客户端时间（而不是跨客户端转换），所以在通信中使用UTC时间，在客户端上使用DateTime.ToLocal()。这样您就完全不需要担心注册表或时区了。