From your frustration,
I suspect you may be unaware that in
typical front-end/engine style,
unix uses two clocks, and timezone locale
setting.
The hardware clock is like a watch for host.
It has a battery that maintains the time
when the host is off,
and which must be replaced/recharged
periodically.
The system clock is a virtual clock
that is set to match the hardware clock
when the host is booted, and daily(?)
thereafter.
The default time reported by date,
and otherwise often used,
is offset from the system clock,
according to timezone set with
environment variable "$TZ".
The hardware clock and the system clock
are normally set to UTC,
a.k.a. "internet time".
You can read the system clock setting as
ksh> date -u
This may be naive,
but is it possible that you have ntp setup,
and configured to use an ntp server,
that is improperly set.
This would account for resetting the time
after a few days.
(ntp would be doing its job of synchronizing
your host clocks.)
If ntp is in use and misconfigured,
after setting the time
and immediately seeing a correct report from
ksh> date -u
wait a few days, and rerun
ksh> date -u
to see major drift.
How can you determine if an ntp client
is running?
Where are the logs?
On my box, I know that ntp is being used,
(due to recent DST problems) but
/etc/ntp.conf and /etc/ntp.drift
appear unused,
ksh> ps -ef | grep ntp
and
ksh> netstat | grep 123
report nothing.
Is it possible that you have the timezone
($TZ) set inconsistently.
This would account for a fixed multi-hour
offset.
(When you reset the time with an inconsistent
timezone, you may offset the hardware clock,
by a fixed number of hours.)
If TZ is misconfigured,
after setting the time
and immediate report from
ksh> date -u
will be offset by hours.
When a hardware clock battery fails,
a drifting clock is usually the first symptom,
but before it reaches hours per day,
the host usually shuts down completely.
Hopefully helpful,
