服务器是否应将其时区设置为GMT / UTC？

与大多数情况一样，“取决于”。

• 你所有的pipe理员/用户都在同一个时区吗？ 也许他们的TZ是合适的。
• 机器是否与当地环境相互作用？ 本地TZ可能会很好。
• 所有的日志都被拉到一个中央位置进行分析吗？ UTC可能会有帮助。
• 机器是否以时间紧迫的方式相互沟通？ UTC可能有助于防止愚蠢的不匹配问题。
• 操作系统供应商（更可能是networking设备）是否有build议？ 考虑一下。
• DST会让你烦恼吗？ 使用UTC。
• 你觉得怎样才能让你的生活更轻松？ 使用它。

我已经完成了所有选项（本地，UTC，任意但一致），并且更喜欢“所有机器的本地时间到家庭办公室”，尽pipe系统pipe理员和用户是在那里，即使机器分散在世界各地。

我们将所有内容都设置为GMT，这使得跨系统的日志文件更简单。

但我认为我们应该放弃时区，所有事情都使用GMT。

正如其他人所说，这取决于。 在这个问题上有一个长期和广泛的经验的大集团已经权衡。该组织是世界各地的军事力量，他们使用UTC（GMT）。

还有一件事要考虑。 如果这些系统支持应用程序代码，则需要了解应用程序是否具有时区知识。 在我参与的一些编程论坛中，我build议date/时间总是以UTC格式存储在数据库中，并为最终用户提供他们如何查看date/时间的选项。

我在一家非常大的托pipe公司工作，我们在全球拥有数据中心。 我们通常将机器时间设置为本地数据中心时间，然后使用所有支持人员所在的时区作为使用工具时转换为的通用时间等。

正如其他人所说，没有一个正确的答案，但这是我们使用的方法:)

这里的政策说，所有的机器都会被当作时区（即物理位置）。 唯一棘手的是将事件日志条目（windows machiens）关联起来，因为时间给了本地时间 – 大多数其他的日志文件总是用UTC来写时间。

但对于Windows用户，RDesktop到服务器（无论什么原因），他们坚持看看UTC？

不完全确定，但我认为是 – 时区在逻辑上是一个机器级别的设置。

由于它们支持的应用程序，我们将机器物理地位于一个时区，并且提前3小时设置。

我们也有开发人员构build软件，期望在服务器之间达到5秒以内的同步，隐式地依靠AD时间进行同步的开发人员，以及谁不会为非同步的情况编写错误检查或处理例程，以及谁声明后来的失败是pipe理员没有把networking时间维持到他们想象的标准的错误。

不要做我们做的事情。 它只会让你痛苦。

为了增加讨论，我们在世界各地设有办事处，每个办事处都有自己的一套networking，应用程序和数据库服务器，每个服务器都有不同的应用程序分支，因此本地时区是一个好主意。在全国范围内讲话。 对于美国的服务器，我们正在向所有地点的中央时间迈进，以匹配我们的主要数据中心，因为使用不同时区的应用程序服务器和数据库正在给开发者一个很难的时间。

Yeller应用程序最近发布了一篇博客文章，build议所有系统pipe理员使用UTC。 这是一个摘录：

Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. 

除了笑话之外，基本上就是说只使用UTC意味着不用打扰夏令时（DST），以及由此带来的错误。