I'm having a problem setting system time. Actually, it seems that the kernel time is in UTC, while the "system" is in the correct timezone.

When I type 'date', I get the correct system time, e.g., as of this
writing:

[root@mail /root]# date
Thu Apr 11 19:48:02 MDT 2002

But, when I edit or create a file, the timestamp is 6 hours in the
future, or UTC:

[root@mail /root]# touch testfile
[root@mail /root]# ls -alF test*
-rw-rw-r-- 1 root root 0 Apr 12 01:49 testfile


My /etc/zoneinfo file points to the correct timezone file:

lrwxrwxrwx 1 root root 34 Apr 12 01:54 /etc/localtime -> /usr/sh
are/zoneinfo/America/Denver

Plus, my /etc/sysconfig/clock file seems to be set correctly:

ZONE="America/Denver"
UTC=true
ARC=false

I run a script in /etc/cron.daily to first set the system time from a
timeserver, then set the hardware clock to local time:

#!/bin/sh
#Script to set time
/usr/bin/rdate -s clock.psu.edu
/sbin/hwclock --systohc --utc

The boot file /etc/rc.d/rc.sysinit runs

/sbin/hwclock --hctosys --utc

So, any suggestions as to what I'm doing wrong or any other script that might be setting time on boot?

Thx.

:smash:

I'm a tad confused myself, since you don't want to use UTC correct? Yet you seem to be using --utc option with hwclock & your sysconfig/clock file says utc=true. Could these be the problems? You may want to specify --localtime instead?

warrenweiss,

You can do one of two things:

1. If your Linux server can run ntp - turn it on and point it to you time server. To do this:

NTP is off until something turns it on. The ntp daemon xntpd is one thing that turns it on. You can turn it off by running any-thing, including hwclock --hctosys, that sets the System Time the old fashioned way.
To see if it is on or off, use the command adjtimex --print and look at the value of "status". If the "64" bit of this number (expressed in binary) equal to 0, 11 minute mode is on. Otherwise, it is off.
If your system runs with NTP mode on, don't use hwclock --adjust or hwclock --hctosys. You'll just make a mess. It is acceptable to use a hwclock --hctosys at startup time to get a reasonable System Time until your system is able to set the System Time from the external source and start NTP mode.
Take out the call to your shell script in the crontab.

2. Remove /etc/adjtime if it exists. Then set the hardware clock manually by doing /sbin/hwclock --set --date="M/D/Y H:M:S" ( M=current month, D=current day, Y=current year, H=current hour, M=current minute, S=current seconds).
Edit /etc/rc.d/rc.sysinit and add /sbin/hwclock --adjust before the /sbin/hwclock --hctosys --utc.
Edit the crontab shell script to receive the time sync from your time server in a variable. Then set the hardware clock to the variable. For Example; /sbin/hwclock --set --date="${newdatetime}"

I do want to set the hardware clock to UTC, but then set the system time with the correct offset.

I originally had the hardware clock in local time and thought perhaps that that was where my problem was.

Use ntp instead of 'rdate', you say? OK...

OK, thanks for the great suggestions. I'll see what this does.

Thx

If your intrested the following sets time automatically:

http://www.tinydeveloper.com/scripts/settime

if you put this in your crontab to run weekly.

on redhat just put the script in /etc/cron.weekly

As it turns out, the problem was with 'ls' and a few other key utilities linked to libc version 5 which, apparently, couldn't determine the correct timezone.

ldd /bin/ls
libc.so.5 => /lib/libc.so.5 (0x4000d000)

ldd /bin/date
libc.so.6 => /lib/libc.so.6 (0x4001a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The correct thing to do would be to fix the libc dependencies. The more correct thing to do would be to alias 'ls' to 'dir' (which works) and forget about it 'til the next OS upgrade.

I had the same problem, what fixed it for me was editing /etc/rc.d/rc.6 and changing the line that sets the hardwareclock
I changed it from
hwclock --localtime -syshtolc
*to*
hwclock --utc syshtolc
Worked great after that, Hope this helps someone.