我在代码中使用TimeZoneInfo.FindSystemTimeZoneById()。
我知道这个方法适用于系统注册表中的id。
所以我想知道，当它进入服务器时，是否有可能无法正常工作，因为服务器注册表中的ID与我本地的ID不一样。
有人知道这件事吗？
虽然可能找不到ID（请参阅其他答案），但如果两台机器都有当前的Windows更新，则不太可能出现不匹配。
即便如此，尽管夏令时和显示名称的定义每年都会发生多次更改，但很少会创建全新的时区，ID一旦建立就永远不会更改。
因此，只要您的服务器具有当前时区的Windows更新，那么您就应该能够处理来自客户端的任何有效输入，即使它们不是最新的。您可以查看此网站上Windows的所有时区更新。
然而，尽管如此，我最好的建议是放弃使用微软时区，转而使用标准的IANA时区。有关详细信息，请参阅时区标记wiki。在.NET中，实现这一点的最佳方法是使用Noda Time库。
TimeZone的东西总是让我困惑，但我的答案是是。有可能在不同的服务器上不起作用。
TimeZoneInfo.FindSystemTimeZoneById()方法使用HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionTime 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()。这样您就完全不需要担心注册表或时区了。