如何檢查 DST（夏令時）是否在 CentOS 不同版本中處於非活動狀態？
我很少有使用 CentOS 7 和 6 作為作業系統的伺服器。以前，夏令時的時間每年更改兩次，作業系統會在每台伺服器上自動執行此操作。
現在突然通過了一項改變夏令時政策的法律。我想確保在這些伺服器上禁用 DST，以便作業系統不會像以前那樣更改時間。我希望這些更改基於我們的中央時間伺服器發生。
在 CentOS 7 上，我可以驗證此命令未啟動 DST：
timedatectl status輸出：
DST active: no但我無法在 CentOS 6 上安全地確認 DST 已停用。我到處搜尋，但找不到顯示此內容的命令或文件。那麼如何檢查 DST 在 CentOS 6 中是否處於非活動狀態？
首先，您必須確定目前時區設置是什麼。如果
TZ設置了環境變數，那就是時區；但如果未設置，則係統預設時區由/etc/localtime.如果
/etc/localtime是 的符號連結/usr/share/zoneinfo/...，則確定目前時區很容易：連結目標路徑名將準確辨識實際時區。但在 RHEL/CentOS 6 中，該
/etc/localtime文件很可能是來自 的時區文件之一的實際副本/usr/share/zoneinfo/...，而不是連結。還有一點小問題：/etc/sysconfig/clock很可能會告訴您在 OS 安裝時選擇什麼作為預設時區，但如果後來通過覆蓋/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據此，America/New_York 時區最近一次從 EST 過渡到 EDT 是在 3 月 13 日，下一次過渡將在 11 月 6 日回到 EST。
如果所選時區的 DST 處於非活動狀態，則這些 DST 轉換描述將不存在。
還有一個挑剔：在任何類 Unix 系統上，作業系統的內部時鐘始終以 UTC 執行，並且所有作業系統內部時間計算都使用與 UTC 等效的 Unix 時間戳處理。當本地時區發生 DST 轉換時，系統不會“更改時鐘”，而只是更改本地時間和 UTC 時間之間的轉換偏移量。
在 Linux 系統上，可以選擇讓電池支持的硬體時鐘在本地時間執行，以便在雙啟動方案中與 Microsoft 作業系統兼容。如果您使用該選項，硬體時鐘將在 DST 轉換時進行相應調整。但是，如果您將 RTC 保持在 UTC 時間（這通常是面向伺服器的 Linux 發行版中的預設設置），那麼由於 DST，永遠不需要實際的時鐘調整。只需適當更改轉換係數即可。