Problems in getting the right time

[Petri Kaukiainen]

Unix date-command gives me the right time, but when a program issues time() and localtime() calls (or using Informix dtcurrent()), the result is six or seven hours behind (depending on different TZ values i have tested). The TZ we're using is EET-2EETDST. We have several HP-UX hosts here and some of then give the same time values both ways but some of them don't. So, how do I correct the times ?

[Andy Monks · Accepted solution]

Firstly, you want to ensure that the TZ is set the same on every machine. Unix stores the time in UTC (aka GMT) and then translates this for display (or calls to localtime() etc).

The time() function should return about the same on all the machines. It's time since epoch (1/1/1970).

Also, ensure that you've not changed the kernel parameter timezone. It should be 420.

Lots of people do that instead of just setting TZ (/etc/TIMEZONE).

The other thing you can do, is run ntp on the machines, so they all have exactly the same time.

http://www.eecis.udel.edu/~ntp/

[Andy Monks]

Calls to time() always produce an answer in UTC (aka GMT). It's then converted by localtime() etc, based upon your TZ setting.

It's worth comparing the value returned by time() on all the machines. It should be the same (or maybe a few seconds out).

Check /etc/TIMEZONE on all the machines is the same.

Check also, that you haven't changed the kernel parameter 'timezone' from it's default of 420. Lots of people do that, instead of changing /etc/TIMEZONE.

You could also run ntp to ensure all the times (in UTC) are the same :-
http://www.eecis.udel.edu/~ntp/

[Jim Welch]

First, is the system time correct? The raw system time is stored in GMT seconds since the epoch. This should be the same on all systems. System commands such as date take the system time and use the local timezone settings to convert the raw system time to the text representation of the local time.
It is not too difficult to have the wrong
system time and the wrong timezone environment variable so that the result shows the correct local time from the output
of the date command.
You can compile and run a simple program such as:
#include
main()
{
time_t t;
t=time((char *) 0);
printf("The raw time is %dn",t);
system("echo "The TZ environment variable is:*$TZ*"");
system("echo 'This results in the following local time:';date");
}

When this is compiled and run you should get
something like:# cc time.c -o time.exe
# ./time.exe
The raw time is 964887236
The TZ environment variable is:*EST5EDT*
This results in the following local time:
Sat Jul 29 12:13:56 EDT 2000

All you systems should have the same raw system time. Everything else is controlled by the way the os converts raw time to local time (TZ environment variable) which can be altered by the user's login initialization scripts (.kshrc, .profile, .cshrc, etc...)

A good way to sync the clock on multiple systems is by enabling NTP via sam. Then any
local time errors should be due to incorrect
timezone settings.

I disagree with the previous statement that
the timezone variable should be 420, unless that is the correct offset for your local timezone. I set mine to what I believe is the correct setting (300), but from what I could tell by experimenting with it and reading the man pages, it's only used if there is no other timezone information available.

Please post something back when you find out what is causing your problem.

[Terja]

A suggestion,

To keep your machine times in sync use ntp (network time protocol). If you are lucky enough to have a firewall that you can sync to a central time clock, fine, if not,
use the machine that drifts the less (IF YOU HAVE a look at the time specs on hp the drift can be quite large). To determine this keep a record of an accurate time set, and check a month later, which machine has deviated the least, should be the ntp master.

.Email me if you want more info on ntp.

PS. I am another Finn, just from Down under.