我很好奇其他管理员在远程管理服务器的上下文中对时区的体验是什么。在我的职业生涯中，我遇到了几个约定；
在某些地方，我遇到了多个相互冲突的约定。我自己的偏好是始终使用 UTC - 没有夏令时。但出于某种原因，似乎大多数人更喜欢使用具有夏令时的当地时间的某种概念。尽管这似乎是一个简单的技术问题，但围绕不断变化的惯例的讨论似乎总是趋向于宗教分裂。
你在用什么？您认为每种方法的优点和缺点是什么？
更改时间后是否需要重新启动服务器？当我更改日期时间并且没有重新启动 crond 时，我遇到了麻烦。
是否还有其他服务在时间更改后可能出现问题？
我们用作源的外部 NTP 服务器之一（当前的主要服务器）似乎没有响应 NTP 调用。不幸的是，在我们的核心路由器 (Cisco 6509) 上，NTP 功能没有像预期的那样切换到辅助 NTP 外部服务器。结果，我们的核心路由器（几乎是我们主要的内部 NTP 源）延迟了 2 分钟。
我计划通过使外部 NTP 源成为当前工作的源来解决外部路由器问题。 我想知道，2 分钟的更改会对我的用户和服务产生多大影响？特别是最近以来，我们严重依赖基于证书的身份验证。
我们是一家 Windows/Cisco 商店。
[核心路由器 1 / Cisco 6509]：
查看两个外部 NTP 服务器（其中主要服务器不响应 NTP 调用）
[核心路由器 2]：
与核心路由器 1（主要）同步，工作外部路由器（次要）
[其他思科网络设备]：
与核心路由器1（主要）、核心路由器2（次要）同步
[域控制器]：
与核心路由器 1 同步
[所有 Windows 客户端/服务器]：
与域控制器同步
我正在编写一个测量网络延迟的 Graphite/Diamond 收集器。具体来说，它应该测量打开与远程服务器上端口的连接所需的时间。它需要通过脚本工作，即键盘上没有人以交互方式运行。
举个例子，给 telnet 提供一个虚构的参数，它可以完全满足我的需要。
time telnet --close-connection-immediately-after-established somehost.somedomain.com 1234
Trying somehost.somedomain.com...
Connected to somehost.somedomain.com.
Escape character is '^]'.
Connection closed automatically after established.
real 0m3.978s
user 0m0.001s
sys 0m0.003s
基本上，在上面的示例中，仅使用内置工具输出 3.978 的命令行方式是什么？
您可以将 telnet 包装在我想的预期脚本中并使其出现问题：
^]
close
……但那看起来相当丑陋。有任何想法吗？
系统和网络管理员通常是非常忙碌的人。杂乱无章的项目、会议、支持票和走廊里的人的口头请求可能会弄得一团糟。过去我们在这里讨论了一些请求跟踪系统，但是您还使用哪些其他方法或工具来管理您的时间以提高效率？
Thomas Limoncelli 的书《系统管理员的时间管理》有一些很棒的想法，但是在现实世界中哪些对您有用，哪些不适合？
在英国，我们是 UTC+1。我使用“日期”设置时间。然而，它不断重置回标准 UTC，我猜是通过 NTP 时间服务器。
我试过用 tzselect 设置时区，但它不会改变时间，它保持在 UTC 而不是本地时间。
Therefore TZ='Europe/London' will be used.
Local time is now: Thu Jun 25 10:57:48 BST 2009.
Universal Time is now: Thu Jun 25 09:57:48 UTC 2009.
上面的输出是正确的，但时间实际上并没有改变。
我要么需要禁用自动更新时间，要么最好正确设置时区。
多国服务器的理想时间和时区设置是什么？特别是考虑到由一个中央 IT 团队管理这些服务器。
目前，我们让每台服务器都使用本地时区。例如中国数据中心的服务器设置了CST。我们德国数据中心的服务器设置为 CEST。时间设置为数据中心的本地时间。（注意：我们总共在 6 个国家/地区拥有服务器）。
当前设置在查看服务器本地日志时很有用（准确了解事件相对于当前服务器本地时间的发生时间）。然而，当查看来自中央系统日志服务器的事件时，它变成了一场噩梦。
我在一个隔离的网络上有两台 linux 机器（A 和 B）。它们必须是时间同步的。机器 A 是间歇性供电的，必须为时间服务，因为它连接到权威时间源 (GPS)。机器 B 仅在机器 A 上电时才上电，但它是嵌入式 linux 设备，其电源状态会经常变化。两台机器都无法访问其他系统。这是一个封闭的网络。
我知道这对 NTP 来说是一项艰巨的任务，因为 NTP 通常希望与多个服务器有联系。我无法让它在机器 B 上正常工作。机器 A 与 GPS 同步得很好，机器 B 可以到达机器 A 甚至进行时间查询，但机器 A 不受信任（也许是它本身？）。在机器 A 启动了一个小时后，情况突然发生了变化，机器 B 开始工作。然而，当机器 A（因此机器 B）出现故障时，机器 B 再次无法找到良好的时间同步。
这是一些 ntpdate 信息。请注意，即使机器 A 的层数为 1，操作也会失败，最后输出相同。
10.10.10.1：服务器掉线：层数太高 服务器 10.10.10.1，端口 123 16层，精度-19，飞跃11，信任000 refid [10.10.10.1]，延迟 0.02614，分散 0.00000 传输 4，在过滤器 4 参考时间：00000000.00000000 2036 年 2 月 7 日星期四 6:28:16.000 原始时间戳：d3a9bdc4.27ebb350 Thu, Jul 12 2012 21:19:00.155 传输时间戳：bc17c803.b42dfffe 2000 年 1 月 1 日星期六 0:25:39.703 滤波器延迟：0.02625 …
我有一个域控制器在 Hyper-V 上的 VM 中运行，时间似乎越来越快，在圣诞节期间它快了 5，这似乎很奇怪！
我知道如何更改时间，我相信我们在 DC 上设置了一个 NTP 服务器并确保在 Hyper-V 上关闭时间同步。
我真的不想继续设定时间。有没有时间过快的原因？
我在某些（硬件）服务器中看到了一种奇怪的系统时间更改行为：在 /var/logs/syslog 中，每条日志消息之前的日期时间有时会更改为随机时间并在下一条消息中恢复正常，如下所示：
2018 年 2 月 22 日 09:09:30 ... 2018 年 2 月 22 日 09:09:32 ... 2610 年 1 月 13 日 15:37:42 ... 2018 年 2 月 22 日 09:09:33 ... 2018 年 2 月 22 日 09:09:34 ...
如示例中所示，日期时间的突然变化可能长达数百年。
我可以确认具有奇怪时间戳的日志消息不是来自任何特定进程 - 它可能对每个进程随机发生。
并且两次异常时间更改之间的持续时间从几分钟到几小时不等（但是，我怀疑异常时间更改可能会更频繁地发生，但其中许多未在系统日志中显示，因为它不是每秒写入日志）。
此外，由于它发生在不止一台服务器上，我认为这不是硬件问题。
关于服务器的更多信息：它们是一个带有一个控制器和几个计算节点的 openstack 安装。每个服务器都有运行的 ntp 服务。控制器配置为从其自己的硬件时钟中获取时间，并且计算节点服务器从控制器同步时间。请注意，每个服务器都有自己的异常时间变化 - 看起来“错误的时间”不是从控制器通过 ntp 同步的。
我怀疑计算节点上的来宾系统（虚拟机）可能会影响它们的主机系统时间。但这并不能解释为什么控制器在没有运行任何虚拟机的情况下会出现同样的问题。
我需要一种方法来检测：谁更改了系统时间以及它是如何发生的？