DST and cron

[Stuart Powell]

I'm an Indiana resident who is being forced to face what the rest of you have dealt with for decades; Daylight Saving Time. I'll not go into the usual rant that this topic initates, but would like some information on how cron deals with the "Spring forward" and "Fall back" situations. Any documentation and links would be appreciated.

Our servers are all set for the big day, but I want to make sure we know what to expect.

Thanks,

Stuart

[James R. Ferguson]

Hi Stuart:

The manpages for 'cron' explain how daylight saving changes (if any) are handled by 'cron' itself:

http://docs.hp.com/en/B2355-60127/cron.1M.html

Regards!

...JRF...

[Pete Randall]

Stuart,

As usual, the man page is your friend. Check the man page for cron, under the "Spring and Autumn Time Transitions" section. It goes into a detailed explanation that should satisfy your curiosity.


Pete

[A. Clay Stephenson]

Assuming that you are up to date on cron patches -- and there have been some cron patches that deal specifically with DST and assuming that you have stopped and restarted the cron daemon since making any tztab changes (or changing /etc/TIMEZONE) then it should be a complete non-event. Do a man cron and look for the "Spring and Autumn Time Transitions" section. It explains this fully.

To test whether or not, you have setup tztab correctly, run the attached Perl script, dst.pl. It will display the exact second before and after the time changes and because it uses the standard libc routines, if this works then all the commands like date will work and all of your application code that uses the standard routines works as well.

[A. Clay Stephenson]

I should add, invoke the Perl script as dst.pl -u for full usage but basically if invoked as "dst.pl", it will display the time transitions for the current year and if invoked as "dst.pl -y 2007" it will do the same for the specified year. It can also display the time remaining until the next transition.

[John Dvorchak]

One thing to look for is that there will be no 0200 hour that day. Any cron jobs that are expected to run between 0200 and 0300 won't run that one time. One more thing to consider in the fall where the jobs set at 0100 hour will run twice. I think I am correct in this, but it bears looking at.

[A. Clay Stephenson]

No, John, properly patched cron executes once in both of those circumstances. You also need to do a "man cron" and then read it.

[Stuart Powell]

John's thoughts are in line with my understanding of the situation. However, I will review the man pages.

[John Dvorchak]

I got this from the man page. Am I reading this wrong or a job scheduled to run at 2:30 will NOT run:

WARNINGS
In the Spring, when there is a nonexistent hour because of daylight
savings time, a command that is scheduled to run multiple times during
the nonexistent hour will only be run once. For example, a command
scheduled to run at 2:00 and 2:30 a.m. in the MST7MDT time zone will
only run at 3:00 a.m. The command that was scheduled at 2:30 a.m.
will not be run at all, instead of running at 3:30 a.m.

[Stuart Powell]

OK, I reviewed the man page. If I understand it correctly then there will be no issues in the fall when we fall back. An entry scheduled to run at 1:30 AM will execute only the first time. Also I believe that means this Spring my job that is scheduled to run at 2:30 AM will actually run at 3:30 AM. Does that assume that the kernel parameter "timezone" has a value of the offset that will happen during the DST portion of the year, which for this part of Indiana that is observering EDT will be 240 minutes? The "timezone" kernel paramater is set to 420 which, to me, would be associated with MDT. Am I missing something here. Before my last reboot I ran â /sbin/set_parms timezoneâ to change TZ to EST5EDT, and that is reflected in the current system setting.
Thoughts?

[James R. Ferguson]

Hi (again) Stuart:

You would only need to set the kernel 'timezone' and 'dst' parameters if you did not configure a 'TZ' value.

The 'TZ' environmenal variable is defined in '/etc/TIMEZONE'by manually editting the file or running '/sbin/set_parms' with an argument of 'timezone'.

The '/etc/TIMEZONE' file is sourced (read) by 'etc/profile' which is how your login sessions derive the system-wide TZ value.

Other programs (Perl, C, etc.) use the 'ctime()' library calls to ascertain this TZ setting too.

Regards!

...JRF...

[A. Clay Stephenson · Accepted solution]

The only gotcha's are that jobs that are scheduled to run multiple times during a non-existant hour will execute but once -- again, if you have applied the cron patches. The kernel paramter timezone only comes into play when there is no TZ setting. When cron is started under /sbin/rcX.d/ the /etc/TIMEZONE value is automatically sourced so that that becomes the TZ value. If you stop cron by executing /sbin/init.d/cron stop and then restart it manually via /sbin/init.d/cron start then TZ takes on the value that was in the environment at that time.

[Stuart Powell]

Thanks to all for your input. I believe that I've got a much better handle on the situation.