Time change utility?

[John Wolfe_1]

Hello Forums Experts:

I know that we in the U.S. change back to Standard Time on October 26th but does anyone know of a utility that will automatically determine when the time changes?
I've thought about doing something with the tztab file but before I start I would like to know if someone already has something that will work.

Thanks,
John Wolfe

[Steven E. Protter]

Your system will detect that if TZ variable set.

You can also enable ntp to keep time exactly from your timezone.

/etc/ntp.conf

You can find a list of time servers at http://www.ntp.org

SEP

[A. Clay Stephenson]

I answered something similar a while back but it's not quite what you asked:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x2d195fe8b250d71190080090279cd0f9,00.html

The downside to doing something with tztab is that it's an HP thing and not all flavors of UNIX have it. I vaguely remember doing something 4 or 5 years ago (in Perl, I think) that might be close. I'll see if I can hunt it up.

[Patrick Wallek]

The time on the machine doesn't ever change. The systems keeps UTC time. The value of the TZ variable determines what timezone the system thinks it is in (for cron / at jobs, etc.) and TZ is also used to determine how the time is displayed to you when you use the date command.

The system knows, via the /usr/lib/tztab file, when to display the time differently. There really isn't anything you need to worry about on your system as far as the time change goes.

[John Wolfe_1]

Thanks, Steven. I know that NTP will keep the time set correctly. I also know than cron and at will work even when the time changes. NTP won't tell me when the next change will occur. I'm really looking for something that will automatically read the tztab file and display when the time will change.

Thanks,
John Wolfe

[John Wolfe_1]

A. Clay: That was close but not really what I want. I really am looking for something that will read the tztab file and print the dates and times when the time changes.

Patrick: I know that the system will handle the time changes automatically. This is needed for user notification.

Thanks,
John Wolfe

[Jeff Schussele]

Hi John,

Shells are dependent on the TZ variable & if it's a set with a ?STX?DT like CST6CDT then it knows about the time change.
For anything else (daemons?) that don't have $TZ, then kernel parameters timezone & dst take care of this.

But if you want to figure the day of the month then /usr/lib/tztab file ought to give you all you need to pass to Clay's date hammer (caljd.sh or caljd.pl) to tell you what day of month it would be. You should just have to pass it the year, month, & day of month range.

So for this year you pass it 2003, October & 25-31 using the proper parms (sorry I don't know them off the top of my head) & it will give you the day. Then the hour (3) & minute (0) are fixed.

Rgds,
Jeff

[Jeff Schussele]

Oops, I guess you might have to pass it the day of week as well - Sunday (0).

But I see that Clay doesn't think it can do this. I'm crestfallen - the MIGHTY data hammer cannot do this? Tell me it ain't so!

Rgds,
Jeff

[A. Clay Stephenson · Accepted solution]

Okay Steve:

I found it. It's called dst.pl. I found that I made a small change in 2001 so that Windows could use it as well (if you have one one the free Perls for Windows -- www.activeperl.com).

Invoke as dst.pl -u for usage but here are a few examples.

dst.pl
will display the time changes for the current year and current TZ.

TZ=EST5EDT dst.pl -y 2004
will display the time changes for 2004 in Eastern (US) time.

If using a TZ that does not change (e.g. GMT0) then nothing is printed and a non-zero result is returned.

You can change the output format to something more to your liking but this should be very close. Note: It does use tztab but not directly. Perl relies upon the underlying ctime() and strftime() functions so if they use tztab (again, not all UNIX's have it), this script implicitly uses it. That is why it will even work on Windows what don't know nothing about no /usr/lib/tztab.

[A. Clay Stephenson]

One thing John:

You may need to change the "shbang" to point to something other than /usr/bin/perl.
e.g.
#!/opt/perl/bin -w

although I always soft link whatever is the "real" Perl executable to /usr/bin/perl.

[A. Clay Stephenson]

Hi (again) John:

In looking over the code, I discovered a small (and harmless but embarassing booboo). The -y year parameter should really have subtracted 1900 since the time functions expect years since 1900 but because of the kindness of the libc routines, 2004 (instead of 104) worked. It worked fine under HP-UX and Windows but there might be a problem under other versions. This new versions corrects that possible error.

Regards, Clay

[John Wolfe_1]

Hi Guys:

A. Clay's script worked great. I'll download his new version but the old version seemed perfect to me.

It actually displays this:
Sun Apr 06 01:59:59 PDT 2003 --> Sun Apr 06 03:00:00 PST 2003
Sun Oct 26 01:59:59 PST 2003 --> Sun Oct 26 01:00:00 PDT 2003

Thanks for all your help.

Regards,
John Wolfe

[A. Clay Stephenson]

Hi John:

I'm glad you were able to use the script but there seems to be a problem in your output:

Sun Apr 06 01:59:59 PDT 2003 --> Sun Apr 06 03:00:00 PST 2003
Sun Oct 26 01:59:59 PST 2003 --> Sun Oct 26 01:00:00 PDT 2003


***** SHOULD BE *****

Sun Apr 06 01:59:59 PST 2003 --> Sun Apr 06 03:00:00 PDT 2003
Sun Oct 26 01:59:59 PDT 2003 --> Sun Oct 26 01:00:00 PST 2003

Was this a typo that reversed the PST/PDT's or did you possibly have an incorrect TZ setting PDT8PST rather than the correct PST8PDT or (horrors) do I have a bug?

Clay

[John Wolfe_1]

Hi Clay,

The problem was my bad typing. The display was correct. I should have copied and pasted the display but I typed it in instead. The script is fine.

Regards and thanks,
John

[Bill Hassell]

For accuracy, it should be noted that timezones have nothing to do with astronomy but are 100% political. This means that tztab (or whatever mechanism is used in other opsystems) may be incorrect until every country has been polled to see how they will handle daylight saving this year (or next). In the US, Indiana has a strange policy. And some countries may use half-hour (central Australia) boundaries. HP-UX is particularly simple to keep in step with the politics of timezones as new rules and/or new zones can simply be added to the tztab file.

[John Wolfe_1]

Thanks Bill H. for your always insightful comments.

I have just finished a script which automatically emails my users and displays the time change data with a notice that all normally scheduled jobs will continue to function without change. I combined A. Clay's earlier answer with his dst.pl script to get just the right approach.

I continue to be amazed at the level of knowledge to be found in the Forums. Often, I can better and faster answers here than from our paid support contracts.

Thanks to everyone who responded.

Regards,
John Wolfe

[Paulo Marques]

I've made some significant changes to the dst.pl script, to make it more flexible and usefull to me.
I hope you think the same !

Give it a try !

Best Regards,
Paulo Marques