time off by 1 hour

[Mike Miller_8]

I recently applied the QPK1100 patches to an L1000 server running HP-UX 11.0 and found out that the time returned from the 'call time(mytime)' routine returns a time that is off by 1 hour. If I recompile the code it works fine. Due to SQA requirements though I can not recompile the codes. I've tried changing the tztab file in /usr/lib setting the date to 1999 but as per what I found. I'd rather not have to back out the pathes. Has anyone else seen a problem like this and if so what did you do to fix it ?

[Bill Hassell]

tztab does not change time unless your current value of TZ matches an entry in tztab. Start by running the two versions of the program with TZ explicitly set. Note also that a program can behave differently if you patch shared libraries used by your program. There are several TZ and tztab problems mentioned in the libc patch: PHCO_33609 including a mention about changing tztab but the memory cached version is not updated.

[Mike Miller_8]

I found out that by modifying the tztab file as follows I can get the returned time from the intrinsic function 'time' to corrently return the time given by the 'date' command. The '...' are a placer for non-modified lines. I changed the CDT5 to CDT4.

CST6CDT
...
0 3 1-7 4 1987-2038 0 CDT4
...

The environmental var TZ is set as follows :
# echo $TZ
CST6CDT

I'm looking through PHCO_33609 to see if I can find any clues.

[Bill Hassell]

You don't happen to be in Indiana by chance? (just a guess) It turns out that Indiana has it's own rules when it comes to local time. As you might not know, timezones are always political and Indiana is no exception. There are two special timezones in Indiana and they are defined in tztab. Check that your /etc/TIMEZONE file correctly selects the correct Indiana TZ value.

[Bill Hassell]

Almost forgot, you need PHCO_34673 (11.00) for the latest tztab which includes the daylight saving changes for next year.

[Bill Hassell]

There is a possibility that the wrong timezone was used when setting the system time. Use date -u to see the current GMT time for the system. Compare that with:

http://tycho.usno.navy.mil/cgi-bin/anim

If this page does not match date -u, your internal clock wasn't set correctly because of the TZ definition the last time it was changed.

[Mike Miller_8]

The time when using date -u on several servers match. I'm going to apply PHCO_33609 and PHCO_34673 to one of our test servers and see if it helps.
Rebooting the test server had no effect so my initial idea that it may have something to do with the cache'd tztab info must not be related.

[Mike Miller_8]

The problem only appears to be in codes that haven't been re-compiled since around 1995. This leaves me with 3 codes that would need to be re-compiled to remove the problem. I have installed the PHCO_33609 and the PHCO_34673 and it didn't fix the problem. Recompiling the Fortran codes does fix the issue for that code. I must assume that there is an old timezone subroutine that is causing the problem and recompiling it links it to a newer version of that code. I am looking into how much work it would be to push a re-compile change through our SQA process. Checking out a code typically takes around 1 month. I will try and push the re-compile as a platform verification type change which will take much less time.

If anyone still has any ideas on other things to try I'd appreciate it.

[Bill Hassell]

10 year old code...yeah, it definitely sounds like old libraries and/or obsolete or tricky code. As you might expect, old code needs to be refreshed once in a while. 11.00 is pretty old now (goes out of support this year) so you have a much larger issue coming up: migrating to 11.23.

[Mike Miller_8]

Is there a tool out there that will check my current system's hardware/software etc that will tell me if there is any hardware that isn't compatible with 11i ?