我有几台使用 CentOS 7 和 6 作为操作系统的服务器。以前，DST 时间每年更改两次，并且操作系统会在每台服务器上自动执行此操作。
现在突然通过了一项法律，改变了夏令时的政策。我想确保这些服务器上禁用 DST，以便操作系统不会像以前那样更改时间。我希望这些更改基于我们的中央时间服务器发生。
在 CentOS 7 上，我可以验证此命令未激活 DST：timedatectl status
输出：DST active: no
但我无法在 CentOS 6 上安全地确认 DST 已停用。我到处搜索，但找不到命令或文件来显示这一点。那么如何检查 CentOS 6 中 DST 是否处于非活动状态？
答案1
首先，您必须确定当前的时区设置是什么。如果TZ设置了环境变量，则为时区；但如果未设置，则系统默认时区由 确定/etc/localtime。
如果/etc/localtime是到 的符号链接/usr/share/zoneinfo/...，则确定当前时区很容易：链接目标路径名将准确标识实际时区。
但在 RHEL/CentOS 6 中，该/etc/localtime文件很可能是来自 的时区文件之一的实际副本/usr/share/zoneinfo/...，而不是链接。还有一个小问题：/etc/sysconfig/clock很可能会告诉您选择什么作为默认时区在操作系统安装时/etc/localtime，但如果后来通过用来自 的另一个时区文件覆盖来更改时区/usr/share/zoneinfo/，则 中的信息/etc/sysconfig/clock可能不再是最新的。
因此，如果安装操作系统后时区有可能发生更改，您应该将该/etc/localtime文件的内容与其（假定的）原始内容进行比较/usr/share/zoneinfo：
. /etc/sysconfig/clock
diff /etc/localtime /usr/share/zoneinfo/$ZONE && echo "Confirmed: timezone is $ZONE." || echo "Despite appearances, timezone is NOT $ZONE."
一旦知道了时区的正确名称，您就可以使用此命令查看该时区已知历史和预期未来的任何 DST（和其他）转换事件，使用以下命令：
zdump -v <timezone name>
由于此列表可能每年包含两次 DST 转换（四行），一直到 2499 年左右，因此您可能需要稍微限制一下该列表。例如：
zdump -v -c 2020,2025 America/New_York
America/New_York -9223372036854775808 = NULL
America/New_York -9223372036854689408 = NULL
America/New_York Sun Mar 8 06:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 8 07:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 1 05:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 1 06:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 14 06:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 14 07:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 7 05:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 7 06:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 13 06:59:59 2022 UTC = Sun Mar 13 01:59:59 2022 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 13 07:00:00 2022 UTC = Sun Mar 13 03:00:00 2022 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 6 05:59:59 2022 UTC = Sun Nov 6 01:59:59 2022 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 6 06:00:00 2022 UTC = Sun Nov 6 01:00:00 2022 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 12 06:59:59 2023 UTC = Sun Mar 12 01:59:59 2023 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 12 07:00:00 2023 UTC = Sun Mar 12 03:00:00 2023 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 5 05:59:59 2023 UTC = Sun Nov 5 01:59:59 2023 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 5 06:00:00 2023 UTC = Sun Nov 5 01:00:00 2023 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 10 06:59:59 2024 UTC = Sun Mar 10 01:59:59 2024 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 10 07:00:00 2024 UTC = Sun Mar 10 03:00:00 2024 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 3 05:59:59 2024 UTC = Sun Nov 3 01:59:59 2024 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 3 06:00:00 2024 UTC = Sun Nov 3 01:00:00 2024 EST isdst=0 gmtoff=-18000
America/New_York 9223372036854689407 = NULL
America/New_York 9223372036854775807 = NULL
据此，美洲/纽约时区刚刚于3月13日完成了最近一次从EST到EDT的转换，下一次转换将于11月6日回到EST。
如果 DST 在所选时区处于非活动状态，则这些 DST 转换描述将不存在。
还有一个挑剔：在任何类 Unix 系统上，操作系统的内部时钟总是，总是以 UTC 运行，并且所有操作系统内部时间计算均使用 UTC 等效的 Unix 时间戳进行处理。当本地时区发生 DST 转换时，系统不会“更改时钟”，而只是更改本地时间与 UTC 时间之间的转换偏移量。
在 Linux 系统上，可以选择让电池供电的硬件时钟以本地时间运行，以便在双启动方案中与 Microsoft 操作系统兼容。如果您使用该选项，硬件时钟将在 DST 转换时进行相应调整。但是，如果您将 RTC 保持为 UTC 时间（这通常是面向服务器的 Linux 发行版中的默认设置），则由于 DST，因此不需要实际的时钟调整。只是适当地改变转换系数。