我很好奇其他管理员在远程管理服务器的环境中对时区有何经验。在我的职业生涯中，我遇到过几种惯例；
- 永远、永远、永远使用 UTC。
- 永远、永远、永远使用基地总部所在地的时区。
- 使用管理人员的当地时间。
- 使用服务器所在地的当地时间。
在一些地方，我遇到了多个相互冲突的惯例。我个人的偏好是始终使用 UTC - 不采用夏令时。但出于这样或那样的原因，似乎大多数人更喜欢使用某种当地时间概念，并采用夏令时。虽然这似乎是一个简单的技术问题，但围绕改变惯例的讨论似乎总是趋向于宗教分裂。
您使用的是哪种方法？您认为每种方法的优点和缺点是什么？
答案1
- 硬件时钟应始终为 UTC。始终如此。
- 时区设置可以是任何方便的设置。通常情况下。有时也应该是 UTC。
UTC 受欢迎的一些原因：
- 夏令时规则会发生变化，更新并不总是及时发生。UTC 可以解决这个问题。
- 当需要比较不同位置的服务器的日志时，UTC 是一个很好的通用标准。
- 通常，当服务器位于不同位置时，人员或应用程序（或两者）必须在执行数据库插入等操作时处理时间转换。如果您有一个转换（到 UTC），那么很多比必须从一个 TZ 转换到另一个 TZ（因服务器、TZ 而异）更容易做到正确。
答案2
我更喜欢选项 4。是否以 UTC 格式存储 DateTime 值是服务器上运行的应用程序的责任。
此外，当服务器记录系统事件日志时，能够将本地事件与日志条目关联起来也是件好事。例如，如果数据中心在当地时间报告网络中断，您可以轻松识别发生的任何问题，而无需在脑海中转换时间值。
答案3
不，不，一千个不。
有两种类型的程序员...那些理解本地时间应该用于显示/格式化目的的人仅有的那些把自己逼入绝境的人……他们正在用煤油。
所有事件都应以 UTC 格式记录，并将结果转换为本地时间，以便向用户显示。那些没有做到这一点的人是该死的，那些使用本地时间格式而丢弃时区信息的人更是该死（我正在查看你、Oracle DBA）。
把它想象成一个污点检查...如果你将时间规范转换为本地时间，然后对它进行任何未将其发送到 STDOUT 的操作，你的程序不仅会因致命错误退出，还会删除你的源代码来给你一个教训。
答案4
在我的公司，直到今年，我们所有的服务器都位于一个时区。现在我们的服务器位于 3 个新时区。所有服务器都使用我们的本地时区。这对于日志分析，特别是因为我们有跨 3 个时区的分布式网站。
然而，在一个特殊情况，我们在客户 TZ 中留了一台服务器。应用程序应该在一天中的大部分时间运行，维护任务通常设置为在“夜间”运行。起初，我们将服务器设置在 TZ 中，但维护任务对我们亲爱的“我们在您睡觉时工作”的客户来说太慢了……
UTC 也是一个很不错的选择。除非人们在查看日志时总是参考本地时区（这里就是这种情况）。