Java displays wrong system time.

[venkatesh_5]

we are getting incorrect system date and time when displaying it using java. The date command displays the correct system date and time. The same program runs correctly on a different HP machine that has the smae version of java. Any thoughts ideas ???
# swlist -l bundle
# Initializing...

64-bitDevLibs B.11.00 Cross Platform Development Kit
B6256CA B.11.01.06 HP aC++ Ecom Compiler (S800)
BUNDLE B.11.00 Patch Bundle
HPUXEng32RT B.11.00 English HP-UX 32-bit Runtime Environment
QPK1100 B.11.00.51.01 Quality Pack for HP-UX 11.00 (December 2000)
UXCoreMedia B.11.00 HP-UX Media Kit (Reference Only. See Description)
XSWGR1100 B.11.00.52.2 HP-UX General Release Patches, March 2001
Y2K-1100 B.11.00.B0315 HP-UX Core OS Year 2000 Patch Bundle

[Caesar_3]

Hello!

You see the difrence in time that is just like
your time zone difrence if so than is problem
of calculate with the timezone.
Check how the function that you use to get
time work on unix, what she checks and about
the timezone.

Caesar

[Bill Hassell]

System calls to obtain the current time/date depend on the setting of the environment variable: TZ
All time for HP-UX is kept in GMT (Zulu or UTC) format with no daylight saving jumps. The TZ value causes date/time routines to translate the GMT value using entries in /usr/lib/tztab.

So if you run the Java program from a shell prompt (where date shows correctly) then the Java code should display correctly. Now the question is: how is the Java code run? Is it part of a web page? If so, how is the web server started? In other words, the TZ value must be set for Java (or any executable) to interpret the date/time correctly.

[Erwin Mascardo]

We had a problem like this a while back. If TZ is set properly, check the setting of the kernel parameter "timezone", which is used if for some reason a process doesn't get the value of TZ from its calling process. Out of the box, most HP-UX installations have this set to 420 (minutes west of UTC), or MST7MDT. Set it to what your local time should be, recompile the kernel, and reboot.

[F. X. de Montgolfier]

Hi William,

your problem is almost certainly due to difference between HP-UX timezones and java timezones.
For example, in HP-UX, MET stands for Middle European Time. However, this stands for Middle East Time in Java.

If your timezone is MET-2METDST, HP-UX will thus think that you're in Europe, while Java will think that you're in the middle-east...

If your problem is this one, you can define by yourself new timezones: check your /usr/lib/tztab file, and your manpage:

http://docs.hp.com/hpux/onlinedocs/B2355-90682/B2355-90682.html

Cheers,

FiX

[venkatesh_5]

Hi

The problem is not just the time , it shows some day in 2021,22 and so on and a differnt time for each iteration. I will copy the output here.


This is the output from the HP-UX machine working correctly.

# java Test
2003-06-27 09:58:22.817
2003-06-27 09:58:23.082
2003-06-27 09:58:23.343
2003-06-27 09:58:23.602
2003-06-27 09:58:23.862
2003-06-27 09:58:24.122
2003-06-27 09:58:24.382
2003-06-27 09:58:24.642
2003-06-27 09:58:24.902
2003-06-27 09:58:25.163


This is the output from the machine thats not working correctly

# java Test
2015-02-09 18:07:54.494
2015-12-16 15:28:48.494
2016-10-12 14:14:32.494
2017-08-09 12:33:04.494
2018-06-06 11:09:16.494
2019-04-03 07:54:16.494
2020-01-29 06:03:22.494
2020-11-25 04:16:48.494
2021-09-22 03:38:36.494
2022-07-20 05:35:03.494


I dont' have any clues about the output.

Thanx guys

-Venkat

[Bill Hassell]

The output from the Java code is defintely trash. Timzones will simply adjust the hour but the above output is virtually random dates and times--except for the fraction of one second which is always .494 and that may be significant. My guess is that this is a basic coding error, perhaps a misaligned index or pointer or the wrong type of argument for the system call. The problem isn't related to any kernel settings. Might be Java patches or versions for Java support linraries.

[A. Clay Stephenson]

The first thing that I notice is that the values in the "bad" example show a constant value in the milliseconds field - the least significant section. This strongly suggests a byte alignment problem.

I would compare the two machines veryt carefully. Same OS "bitness"; exactly the same patch levels even on seemingly unrelated patches.

As a first test, I would also display the output from a method that returns epoch seconds (seconds since 00:00 1 Jan 1970). That would really give you a clue as to whether the time itself is wrong or how it is displayed.

[venkatesh_5]

Both the machines have the same version of Java. The only thing I see different between them is the following bundle. I don't see this bundle on the machine that doesn't work correctly.

B8110AA 1.2.2.04.01 Java 2 SDK for HP-UX (700/800), PA1.1 + PA2.0 Add On

I am not able to find this bundle to download. Pls let me know if any of you guys know where to download it from.

Thanx

-Venkat

[Caesar_3 · Accepted solution]

Hello!

You could find it on aplication cd from 03/02

Caesar

[venkatesh_5]

No luck even after installing it. Would this be a hardware failure by any chance ??


-Venkat

[A. Clay Stephenson]

Not a chance because the UNIX date command works perfectly. This is bad code somewhere. Again, if you can modify the Java to display epoch seconds and see if that make sense then you are partway to finding your answer. Is one box running 32-bit 11.0 and the other 64-bit?

Your Quality Packs are also quite old.

[Caesar_3]

Hello!

No it could not be problem of hardware!
Did you check more about the command that
you use in java to get a time, some special
dependences of.

Caesar

[venkatesh_5]

This is the code the developer is using to display date.

import java.util.*;
import java.text.*;

public class Exp
{
public static void main(String [] args)
{
SimpleDateFormat df = new SimpleDateFormat ("yyyy-MM-dd HH:mm:ss
.SSS");
for (int i=0; i < 10; ++i)
{
Date now = new Date();
System.out.println (df.format(now));
long lTime = System.currentTimeMillis();
System.out.println (lTime);
try
{
Thread.sleep (256);
}
catch (InterruptedException e) {}
}
}
}


-Venkat

[venkatesh_5]

Any other options ???

[Caesar_3]

Hello!

I cann't see something wrong in the source
so for now i had no ideas.

Caesar