服务器上的本地时区是否有害？[关闭]

对于其他管理员在远程管理服务器的情况下对时区的体验，我感到很好奇。在我的职业生涯中，我遇到过许多惯例。

1. 始终，始终，始终使用UTC。
2. 始终，始终始终使用基本总部所在的时区。
3. 使用碰巧要管理的人员的当地时间。
4. 使用服务器位置的本地时间。

在某些地方，我遇到了多种冲突的约定。我自己的偏好是始终使用UTC，并且没有夏令时。但是出于一个或另一个原因，似乎大多数人都喜欢使用某些当地时间的概念，以节省日光。尽管这看起来像是一个简单的技术问题，但围绕不断变化的公约的讨论似乎总是倾向于宗教分裂。

你在用什么 您认为每种方法的优点和缺点是什么？

• 硬件时钟应始终为UTC。总是。
• 时区设置可以很方便。通常。有时也应该是UTC。

UTC不错的一些原因：

• 夏令时规则会更改，并且更新并非总是及时进行。UTC使这一点消失了。
• 当需要比较来自不同位置的服务器的日志时，UTC制定了一个非常通用的标准。
• 通常，当服务器位于不同的位置时，人员或应用程序或两者都必须在执行例如数据库插入时处理时间转换。如果您要进行一次转换（到UTC），那么比必须从一个TZ转换到另一个TZ（根据服务器TZ的不同）要容易得多。

我更喜欢选项4。服务器上运行的应用程序负责决定是否在UTC中存储DateTime值。

另外，当服务器记录系统事件日志时，能够将本地事件与日志条目相关联也是很好的选择。例如，如果数据中心报告本地时间网络中断，则可以轻松确定发生的任何问题，而不必转换头脑中的时间值。

不，不，不超过一千次

有两种类型的程序员......那些谁明白，本地时间应该用于显示/格式目的只有和那些画自己到一个角落......他们用绘画煤油。

所有事件都应记录在UTC中，并且将结果转换为本地时间以仅向用户显示。该死的是那些谁不能做到这一点，和双该死的是那些谁的格式本地时间使用丢弃时区信息（我看你，的Oracle DBA）。

可以将其视为污点检查...如果将时间规范转换为本地时间，然后执行任何不会将其发送到STDOUT的操作，则程序不仅应退出并出现致命错误，还应删除源代码以示教你一个教训。

如果可以选择的话，我希望使BIOS时钟保持UTC时间，但实际服务器时间为本地时间。我们没有跨时区，因此统一的日志时间戳并不是3M的问题。

在我的公司中，直到今年我们都将所有服务器都放在一个TZ中。现在，我们在3个新时区提供了服务器。所有服务器均以我们的本地时区运行。这对于日志分析非常有用，尤其是当我们分布了在三个时区运行的网站时。

但是，在一种特殊情况下，我们将服务器与客户TZ留在一起。该应用程序应该在一天的大部分时间都处于运行状态，并且通常将维护任务设置为在“夜间”运行。最初，我们将服务器设置在TZ中，但是对于我们钟爱的“睡觉时我们工作”的客户来说，维护任务的速度太慢了。

UTC也是一个很好的选择。除非人们在查看日志时总是参考本地时区（此处就是这种情况）。

我在UTC上运行所有服务器，并尽快将所有服务器转换为控件。

到目前为止，唯一的例外是星号服务器，我不得不在当地时间离开。将其更改为UTC完全打破了星号。（它的版本为1.6，希望当我今年晚些时候升级它时，这不会成为问题。）