Day light saving

[ossupport55]

Gurus

This is sumthing new to me. Never had to be worried abt it. Environment is RHEL 4 and 5. Can you point me in some direction where i can get to know how to be on top of day light saving settings.

cherrs

[Michal Kapalka (mikap) · Accepted solution]

hi,

check this links :

http://www.vanemery.com/Linux/RH-Linux-Time.html

http://www.cyberciti.biz/tips/update-switch-linux-to-dst.html

mikap

[Matti_Kurkela]

Michal's links look OK.

But here are a few points:

- The main idea is to use a timezone setting that includes the DST transition information. That way the OS will handle the DST transitions automatically. If you think you must change the system clock twice a year for DST on any modern operating system, you're doing something wrong.

- To verify your timezone settings on a Linux system, you can run "zdump -v ".

For UAE, you might run "zdump -v Asia/Dubai". This will list all known past and future time transitions in your timezone, both for DST and other causes.

# zdump -v Asia/Dubai
Asia/Dubai -9223372036854775808 = NULL
Asia/Dubai -9223372036854689408 = NULL
Asia/Dubai Wed Dec 31 20:18:47 1919 UTC = Wed Dec 31 23:59:59 1919 LMT isdst=0 gmtoff=13272
Asia/Dubai Wed Dec 31 20:18:48 1919 UTC = Thu Jan 1 00:18:48 1920 GST isdst=0 gmtoff=14400
Asia/Dubai 9223372036854689407 = NULL
Asia/Dubai 9223372036854775807 = NULL

Hmm... looks like UAE joined to the global timezone system at the beginning of year 1920, and had its own time before that. My timezone file has no DST-related lines for UAE.

The timezone data for my country (that has been using DST since 1981) looks like this:

$ zdump -v Europe/Helsinki |less
[...a lot of lines for past time transitions...]
Europe/Helsinki Sun Oct 25 01:00:00 2009 UTC = Sun Oct 25 03:00:00 2009 EET isdst=0 gmtoff=7200
Europe/Helsinki Sun Mar 28 00:59:59 2010 UTC = Sun Mar 28 02:59:59 2010 EET isdst=0 gmtoff=7200
Europe/Helsinki Sun Mar 28 01:00:00 2010 UTC = Sun Mar 28 04:00:00 2010 EEST isdst=1 gmtoff=10800
Europe/Helsinki Sun Oct 31 00:59:59 2010 UTC = Sun Oct 31 03:59:59 2010 EEST isdst=1 gmtoff=10800
Europe/Helsinki Sun Oct 31 01:00:00 2010 UTC = Sun Oct 31 03:00:00 2010 EET isdst=0 gmtoff=7200
Europe/Helsinki Sun Mar 27 00:59:59 2011 UTC = Sun Mar 27 02:59:59 2011 EET isdst=0 gmtoff=7200
Europe/Helsinki Sun Mar 27 01:00:00 2011 UTC = Sun Mar 27 04:00:00 2011 EEST isdst=1 gmtoff=10800
Europe/Helsinki Sun Oct 30 00:59:59 2011 UTC = Sun Oct 30 03:59:59 2011 EEST isdst=1 gmtoff=10800
Europe/Helsinki Sun Oct 30 01:00:00 2011 UTC = Sun Oct 30 03:00:00 2011 EET isdst=0 gmtoff=7200
[... a lot of lines for expected future transitions up to year 2499...]

- Any Unix-style OS (including all Linuxes) has a system clock (OS clock) that fundamentally runs in UTC time. All timestamps are stored in UTC format, but all time information is converted from/to the user's local timezone for input/output.

The hardware clock that keeps time while the system is powered off may be configured to UTC or local time: on Windows PCs, it is set to local time because MS-DOS originally did it that way. On proprietary Unix systems, it usually uses UTC time. On Linux systems, it is configurable.

- On RHEL systems, the UTC/local selection of the hardware clock is stored in two places: /etc/sysconfig/clock has either "UTC=true" or "UTC=false", and the third line of /etc/adjtime says either "UTC" or "LOCAL".

On RHEL 4 there used to be a bug: if you set the UTC/local selection one way at installation time, and then switched it the other way later, the RedHat configuration tools would change only one of the two locations. If the two locations would not agree, the system clock would be set to incorrect time at system boot.

- If your Linux system is running 24/7, it does not matter much whether the system's hardware clock is running in local or UTC time. But if your system may be shutdown while the DST transition happens, setting the hardware clock to UTC would be a good idea: it allows the OS to unambiguously do the right thing regarding DST in all possible situations.

If the hardware clock is running in local time, there can be an ambiguity at boot time: has the DST transition already been applied to the hardware clock or not?