simple DST test

[brian_31]

I have just run this command on all HP servers(all versions) and please let me know if this is a correct test

cat /usr/lib/tztab|grep 2007

if it returns 2007 then we are fine for DST else you have to either install patch or copy the tztab files from a working machine.

Thanks

Brian

[James R. Ferguson]

Hi Brian:

Well, assuming that you are in the United States using the standard US timezones, *and* assuming that you have at least restarted your 'cron' daemon and any long-running processes since the patch installation, then yes, you are probably OK.

There have been several cycles of DST patches, though, and I would be a bit more introspective of your patch than just a simple match for the string "2007"!

Regards!

...JRF...

[A. Clay Stephenson · Accepted solution]

This is hardly a definitive test. At most, you know that some lines contain "2007". I would also encourage you to install the patches if possible because while editing (or copying the file) will certainly fix you now, it is possible that later (even seemingly unrelated) patches might do a dependency check and fail in no DST patch is detected.

A far better test is to download and execute the attached Perl script, dst.pl. Because it uses the same underlying libc routines that all well-written code does (such as the date command), if it works then you can be reasonably certian that you are good to go.
dst.pl will display the exact seconds before and after the time transitions. You can also check multiple TZ's.

TZ=EST5EDT dst.pl
TZ=CST6CDT dst.pl

or simply "dst.pl" to use the current TZ setting. Invoke as "dst.pl -u" for full usage.

[Steven E. Protter]

Shalom Brian,

The more thorough the test the better. I like A Clay's scripts and wish the DST issue were relavent in Israel.

One caution: Don't set the time backwards on a system running an application like an Oracle database. The internal time database can become corrupted and crash the database.

SEP