对于只有一个或几个站点的小型商店来说，这可能不是什么大问题，但对于较大的组织来说，这是我很好奇的事情。
让所有/大部分服务器都使用 UTC 有什么利弊？这肯定会有助于报告和集中日志记录。还可以通过事件关联进行故障排除或安全审计。人们也不必太担心夏令时的变化。
一个缺点是，如果您希望在本地地理时间的“凌晨 4 点”运行某些操作，则安排自动事件（例如 cron）可能需要一些时间。对于 Unix-y 计算机，您仍然可以通过在 /etc/profile 中设置“TZ”让用户处于本地时区，但对于将 RDesktop 连接到服务器的 Windows 用户（无论出于何种原因），他们是否只能查看 UTC？
答案1
正如大多数事情一样，“这取决于情况”。
- 您的所有管理员/用户是否都处于同一时区？也许他们的 TZ 是合适的。
- 机器是否与本地环境交互？本地 TZ 可能不错。
- 是否所有日志都集中到某个位置进行分析？UTC 可能对此有帮助。
- 机器之间是否以与时间相关的方式进行通信？UTC 可能有助于防止愚蠢的不匹配问题。
- 操作系统供应商（更可能是网络设备供应商）有什么建议吗？考虑一下。
- DST 会让您烦恼吗？使用 UTC。
- 你认为什么能让你的生活更轻松？那就利用它吧。
我已经完成了所有选项（本地、UTC、任意但一致），并且更喜欢“所有机器都使用总部所在地的时间”，因为系统管理员和用户都在那里，即使机器分散在世界各地。
答案2
我们将所有内容设置为 GMT，这使得跨系统关联日志文件变得更加简单。
但我认为我们应该放弃时区，一切事物都使用格林威治标准时间 (GMT)。
答案3
正如其他人所说，这要视情况而定。一个在这个问题上拥有长期和丰富经验的大型团体已经参与其中。该团体是世界各地的军队，他们使用 UTC（GMT）。
还有一件事需要考虑。如果这些系统支持应用程序代码，您需要知道应用程序是否支持时区。在我参加的一些编程论坛中，我建议日期/时间始终以 UTC 存储在数据库中，并让最终用户可以选择如何查看日期/时间。
答案4
这里的政策规定，所有机器都与其本地时区（即物理位置）同步。唯一棘手的是关联事件日志条目（Windows 机器），因为时间是 nlocal - 无论如何，大多数其他日志文件都以 UTC 格式写入时间。
但是对于将 RDesktop 连接到服务器的 Windows 用户（无论出于何种原因），他们是否只能查看 UTC？
不完全确定，但我认为是的——时区在逻辑上是机器级别的设置。