Incorrect time display

[Chris Williams]

Running 5.2.1 on HP-UX 11i

We recently moved to a newer unix box. Same version of the OS. The times and time zones are correct on unix and all the associated PCs. The time stamps in the process log files are correct. The unix date command returns the correct time.

When you call up any of the thread status displays in the qui, regardless of which PC you are on, the Started, Last Rd and Last Wt timestamps are all behind by exactly one hour. They do show the correct time zone however.

Has anyone else experienced this?

Topic

[Michael Hertel]

I’ve never seen your issue before but…

Is the time correct on the “Reported at:” line at the top of the status box?

If you open a shell window from the qdx gui and run the date command, is that time correct?

A quick fix to try would be to bounce the process associated with that thread. Also, are all threads reading incorrectly or just those in a common process?

-mh

[Chris Williams]

The “reported at” time is also incorrect.

The unix date command reports the correct time. (I’ve never been able to get the QDX shell window to work. That’s a whole different issue. It closes as soon as it opens. I just open a regular telnet session from the PC. )

The “Engine idle” timestamps in the process logs are the correct time.

All threads in all processes report the same incorrect times in the gui, regardless of which PC is running the gui. I’ve bounced the individual processes as well as the entire engine, and that has not resolved the problem.

Maybe I wasn’t watching where I was going and wound up in the Twilight Zone.

[Michael Hertel]

I’ve had the same problem before with the shell window.

You said earlier “The time stamps in the process log files are correct.”

Can you look at the process log via the gui and see the correct timestamps?

Also, look in the bottom right hand corner of the gui. Are you telneting to that hostname when you check the date command?

[Chris Williams]

Looking at the process logs via stand-alone telnet and thru the gui’s “watch output”, the timestamps are correct. I would expect to see that since “watch output” is basically just tailing the log file and displaying the contents in the gui and not actually manipulating any of the data.

Yes, I’m looking at the correct host and site.

[Michael Hertel]

Ok, sorry I couldn’t be of help.

[Chris Williams]

Thanks for helping. It’s always better with more than one mind exploring the problem, not to mention having company in the Twilight Zone.

Cheers.

[John Mercogliano]

This is a shot in the dark but check the date/time properties on the pc(I’m assuming windows), look at the time zone tab and see if the “Automatically adjust clock for daylight savings changes” is checked.

This is definitely not a unix problem but a pc problem.  

Also, what time zone are you in? Your not in Australia are you:)  This could be a java 1.3 problem interpreting the correct time from the PC clock. Australia is just one of the places potentially affected by this.  

Take a look at this link:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4252829

Hope this helps.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[John Mercogliano]

One other thought, because the gui is statically linked to java 1.3 you can try copying the tzmappings file from the lastest release of java over the cloverleaf version.  You might need to reboot for it to take affect.  

Thats all the bright or not so bright ideas I have on this one.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Russ Ross]

I was able to duplicate your situation by changing the time zone on my PC but leaving the actual time unchanged.

My bet is that you have the time correct set correctly on the Cloverleaf server and your PC but one of them is set to a different time zone.

If the command

hcimsiutil -dd thread_name

gives a different result from what is in the GUI that is even a better bet that the time zones are not the same even though the actual time is.

On my Cloverleaf server running AIX I do

date

and get

Fri Nov 17 13:21:02 CST 2006

then on my windows client PC, I go to

control p[anel –> date & time –> time zone

and make sure both are CST

I did a test and changed my PC to EST and got a similar result to what you described.

One thing I noticed is that my change was not noticeable to the GUI until I closed the IDE and relaunched it.

So be sure to close your IDE and relaunch it.

Russ Ross
RussRoss318@gmail.com

[Chris Williams]

Mystery solved.

When the new unix box was set up by the vendor, they put an incorrect value in /etc/TIMEZONE. The solution was a matter of changing TZ=CST5CDT to TZ=CST6CDT and rebooting.

[Michael Hertel]

It’s good that you solved your mystery, but how is it that the unix date/time commands reported the “correct” time?

[Russ Ross]

Thanks for sharing your discovery.

Changing TZ=CST5CDT to TZ=CST6CDT makes perfect sense out of your problem.

The actual time setting & time zone (CST) was correct on both your UNIX box and PC.

The problem was the relative time change value of 5 hours which should of been 6 hours.

That likely explains why everything looks great on each of the boxes (PC & UNIX box) but only has a problem when the 2 boxes adjust the time between each other.

The problem is so well hidden it almost seems like someone was playing a practicle joke on you.

I say that becuase I had to work my way through some practicle jokes when I first came to work here.

A couple of them I thought were pretty good were:

Quote:

– when I launched an xterm there were no letters because the forground and background had been set to the same color, which makes it hard to debug without any visible text.

– putting tape over the inside of my phone receiver so I could here the caller but the caller couldn’t here me.

I can see why it took some time to figure out the puzzle.

Did you laugh or cry when you made the discovery because I found it a bit amusing.

I was curious to locate my TZ=CST6CDT setting and found it located in /etc/environment on our AIX box.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies