我的雇主位于欧洲（CET），因此我们使用夏令时，这需要每年两次来回移动一个小时。我们的服务器在不同位置的云中运行。设置所有基础设施的员工已经消失了。他决定使用 UTC 作为所有服务器上的系统时区（当前为 Ubuntu 18.04、20.04 和 22.04）。
这并不理想，因为您必须在心里为日志文件中看到的每个日期添加 1/2 小时，具体取决于一年中的时间（夏季 +2 小时，冬季 +1 小时）。一些 cronjobs 的时间也需要每年调整两次，因为任务应该在 CET 中午运行。
是否有充分的理由（仍然）使用 UTC 作为系统时区？或者我应该切换到 CET，以便我的 cronjobs 和日志文件更好地与挂钟保持一致？
答案1
是否有充分的理由（仍然）使用 UTC 作为系统时区？
是的，一点没错！考虑 2023 年 10 月 29 日 02:30 发生的一件重大事件。日志消息已正确生成。 （此日期/时间的相关性在于，整个欧洲的时钟在当天早上拨慢一小时，而对于 CEST/CET 切换时间为当天凌晨 3 点。）
如果您运行的是 UTC，则时间戳是明确的*。您可能需要转换为 CEST/CET，但您肯定知道绝对时间。另一方面，如果您按照当地时间跑步，您首先需要尝试确定这是 02:00 到 03:00 期间的第一次还是第二次。根据日志消息的数量，这可能是不可能的。
Cron 作业曾经是一个问题，但按照建议使用CRON_TZ或迁移到计时器单元systemd另一个答案会巧妙地解决这个问题。
* 除了偶尔的闰秒，即如所提到的阿科斯塔迪诺夫
答案2
我真的可以理解您阅读日志的痛苦，但我不想与我的美国和德国同事讨论日志文件中的时间，在每年大约两周的时间里，夏令时影响了一个大陆，但不影响另一个大陆。就我个人而言，虽然这肯定与主要在本地使用的服务（例如打印服务器 - 不像亚利桑那州的某人会在我的德国南部打印机上打印）相关，但我在邮件服务器日志中发现了除了 UTC 时间戳之外的任何内容令人困惑。
关于你的 cron 工作：我正在慢慢地尝试让自己摆脱良好的 ole crontab，转而使用 systemd 计时器单元。他们有一片OnCalendar=田野，这需要时区规范！所以，您仍然可以说，嘿，太棒了，早上 7:00 在柏林，RFC 2324 传输开始，或者其他什么。
总而言之，是的，对于服务器来说，请保持 UTC。但是，老实说，我认为一致性这里比“穆勒所认为的行政美感”更重要。如果您的管理范围的其余部分/相邻团队和用户期望 CET，那么请务必：使用 CET。事情应该有效。
为了轻松：
1 我可能是个异类。我的机械手表也是 UTC。
答案3
服务器应始终存储 UTC。当地时间是只有人类才需要看到的表示层问题。如果您作为用户想要查看一些带有时间戳的数据，那么您可能希望在您的时区中查看它，而不管服务器认为它是什么。
UTC 对每个人来说都是明确的（包括闰日/秒），并且永远不会与任何夏令时重叠（特殊情况除外）。
当地时间可以（并且确实）每 6 个月重叠一次，因此，如果您查看使用当地时间作为时间戳的日志，则 3 月似乎会缺少该小时，而 10 月则会有该小时两次。
答案4
您会看到 UTC 的缺点（很难在心理上转换为当地时间）。您没有看到 UTC 的优点，或者更确切地说没有看到问题：让每个服务器都同意时间是非常非常有价值的。如果您将服务器更改为当地时间，您很快就会发现。
将您的服务器保持在 UTC。您可以考虑创建一些工具来帮助您检查日志。例如，这样的工具可以显示当地时间的日期。或者及时将日志紧密地分组在一起。或者用“id1”、“id2”等替换 32 字节不可读的 id，这样您就知道哪些日志行属于同一操作。或者删除 1000 条几乎相同的日志行。