0

I have few servers with CentOS 7 and 6 as OS. Previously, the time was changed twice a year for DST and the OS automatically did this on each server.
now suddenly a law has been passed that changed the policy of daylight saving time. I wanted to make sure that DST are disabled on these servers so the OS does not change time like it did before. I want these changes happen based on our central time server.
on CentOS 7 I can verify that DST is not activated by this command: timedatectl status
output: DST active: no

but I can't safely confirm on CentOS 6 that DST is deactivated. I searched everywhere but i couldn't find a command nor a file to show this. so how to check if DST is inactive in CentOS 6?

waltinator
  • 4,439
  • 1
  • 16
  • 21
BlackCrystal
  • 716
  • 14
  • 39
  • Where are you located that changed the policy on DST? In the US, the senate passed a bill but it has not been taken up by the house and it's not clear that the president would sign it. No legal changes here. – doneal24 Mar 16 '22 at 12:08
  • 1
    see this https://unix.stackexchange.com/q/693875/72456 if you are also from Iran country that recently going to cancel DST transition (but not finalized yet). you will need to apply a custom timeZone to prevent from DST changes and it will keep the time in standard form +3:30 – αғsнιη Mar 16 '22 at 15:43

1 Answers1

1

First, you'll have to determine what the current time zone setting is. If the TZ environment variable is set, that's the timezone; but if it's not set, the system default timezone is determined by /etc/localtime.

If /etc/localtime is a symbolic link to /usr/share/zoneinfo/..., then determining the current timezone is easy: the link target pathname will exactly identify the actual timezone.

But in RHEL/CentOS 6, the /etc/localtime file will most likely be an actual copy of one of the timezone files from /usr/share/zoneinfo/..., not a link. And there is a little wrinkle: /etc/sysconfig/clock will most likely tell you what was chosen as the default timezone at OS installation time, but if the timezone was later changed by overwriting /etc/localtime with another timezone file from /usr/share/zoneinfo/, the information in /etc/sysconfig/clock may no longer be up to date.

So, if there is the slightest chance that the timezone might have been changed after the installation of the OS, you should compare the contents of the /etc/localtime file to its (supposed) original in /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."

Once you know the correct name of the timezone, you can use this command to view any DST (and other) transition events in the known history and expected future of that timezone, using the command:

zdump -v <timezone name>

Since this list may include two DST transitions (four lines) per year all the way to year 2499 or so, you may want to restrict the list a bit. For example:

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

According to this, the America/New_York timezone has just had its most recent transition from EST to EDT on March 13, and the next transition will be back to EST on November 6.

If DST was inactive for the chosen timezone, those DST transition descriptions would not be there.

And a nitpick: on any Unix-like systems, the internal clock of the operating system always, always runs in UTC, and all OS-internal time calculations are handled using UTC-equivalent Unix timestamps. When a local timezone has a DST transition, the system does not "change the clock", but just changes the conversion offset between the local and UTC time.

On Linux systems, there is an option to have the battery-backed hardware clock run in local time, for compatibility with Microsoft OSs in dual-boot scenarios. If you use that option, the hardware clock will be adjusted accordingly at DST transtions. But if you keep the RTC in UTC time (which is generally the default in server-oriented Linux distributions), no actual clock adjustment will be needed because of DST, ever. Just the conversion factor is changed as appropriate.

telcoM
  • 87,318
  • 3
  • 112
  • 232