Operating System - HP-UX
1834442 Members
2169 Online
110067 Solutions
New Discussion

tztab updated but no change in time

 
Catherine Hurley
New Member

tztab updated but no change in time

Hi guys,
I am having problems with updating to daylight saving time on a machine. I have a script that runs on a cluster of machines to change the clock to daylight saving time. The script executed and updated the tztab file on all machines. The change took effect immediately on all machines except one. I do not want to reboot the machine, is there any way of making the change take effect?

7 REPLIES 7
IT_2007
Honored Contributor

Re: tztab updated but no change in time

what OS and model of that server?
Catherine Hurley
New Member

Re: tztab updated but no change in time

HP-UX 11.11 and Hp 9000
Bill Hassell
Honored Contributor

Re: tztab updated but no change in time

tztab is simply a reference file. So you look at the entry for the TZ value you are testing to see if it is correct. The time library calls evaluate time based on the current value of TZ. You can see the change by running the date command with a different TZ value:

TZ=EST5EDT date
TZ=PST8PDT date

Are you checking when the daylight saving takes effect by using Clay's Perl script?


Bill Hassell, sysadmin
Catherine Hurley
New Member

Re: tztab updated but no change in time

no we have our own script that executes, reads a timezone file and updates the tztab. When you call localtime()on the machines, the others are correct but this one is not. The TZ value is the same on all machines..IST-2IDT. This machine is a 700 series and the others are 800series, would this make a difference?
A. Clay Stephenson
Acclaimed Contributor

Re: tztab updated but no change in time

No, at 11.11 the 700 Series and 800 Code Series is unified. Eventhough the TZ settings on all the machines are the same this does not mean that the tztab entries are all the same. I suspect that you have not installed the latest libc patch so that the tztab entry is cached and is not being re-read. Check to see if PHCO_34275 is installed. Bill mentioned my Perl script. It does not update tztab but is used to test when the actual time transitions occur. It displays the exact second and the second before that the time transition occurs for a given TZ setting. Because it is written in Perl, it will even test time transitions on Windows boxes if one of the freely available Perl's is installed. Invoke as "perl dst.pl -u" for full usage. "perl dst.pl" will display the time transitions for the current year and "perl dst.pl -y 2007" will display the time transitions for 2007.




If it ain't broke, I can fix that.
Bill Hassell
Honored Contributor

Re: tztab updated but no change in time

No, the model will make no difference. 11.11 is the same code on all PARISC machines. Now I'm confused about 'updating' tztab. It needs to be patched about once a year, less if politicians doesn't mess with daylight saving so often. Now HP-UX isn't quite like other flavors of Unix. The library routines for localtime(), ctime(), etc, perform the conversion based on the immediate setting of TZ. Change TZ and the time adjusts according to the rules in tztab *OR* if the entry is not found, the rules in the environ man page.

The attached perl script for verifying daylight saving time uses the current TZ value plus the localtime() library to determine when daylight saving changes will occur -- essentially verifying the rules in tztab.

Now this means that a script is totally unnecessary to 'change' the clock on HP-UX. HP-UX keeps only one time: GMT. No daylight saving changes, no jumps in time, just GMT (ie, Zulu or UTC). The returned value from localtime() is simply translated according to the rules in tztab and these rules can be as arbitrary as the politicians that legislate the changes. And it's all automatic.

SO if you change the tztab entry for IST-2IDT, then *IF* the value of TZ is set to IST-2IDT, you would see the change. If there is a spelling error and grep $TZ /usr/lib/tztab produces no result on the problem machine, that is the problem. You can verify that TZ works on the library routines by using commands like this:

date
TZ=IST-2 date
TZ=ZZZ-2 date
TZ=BILLH-2 date

As you will see, the 3-letter location is just an arbitrary 3+ letters (man environ) and the offset (-2) is from GMT. But important to know: TZ is globally set as users login normally, that is, they run /etc/profile and ~HOME/.profile by sourcing the file /etc/TIMEZONE. If TZ is incorrect, look in that file, then /etc/profile and finally .profile. Also check the man page for tztab to see how the two time definitions (standard and daylight) are created.

The attached script will return the two changeover points for any timezone listed in /usr/lib/tztab (oh, there is no /lib in HP-UX -- it is just a symlink). Just run it with a temp value (commandline assignment) for TZ to test. You can check years in the past or in the future:

dst.pl
TZ=IST-2IDT dst.pl
TZ=IST-2IDT dat.pl -y 2007
TZ=GMT0BST dst.pl
TZ=EST5EDT dst.pl


NOTE: if the entry for $TZ is not found, the library routines default to EST5EDT rules without comment. (man environ) To see the dst.pl options: dst.pl -?


Bill Hassell, sysadmin
IT Response
Esteemed Contributor

Re: tztab updated but no change in time

Let's not forget that Java/lib++.a/rwtools and DCE will be affected.

For java check www.hp.com/go/java. There is a link off the main page in red. Also, before month end there may be a tool available, similar to sun and IBM's that will change Java TZ files without having to install a whole new Java version.
Also check:
8606420800 - YK changes in librwtool and in lib++.a
fix
Applications linked shared can just apply the aC++ Runtime patch.
If linked archive, the application must be relinked.

For librwtool the following patches exist:
[PHSS_33941/PACHRDME/English] 11.00
[PHSS_33942/PACHRDME/English] 11.11
[PHSS_34041/PACHRDME/English] 11.23

lib++.a is only fixed with the A.03.70 release.



8606430960 - DCE and Daylight Saving changes in U.S.


Fix Release : - 11.31
11.11 : - December 2006
11.23 : - December 2006
cheers,
Nick