The "seconds since 1970" timestamp is specifically defined as UTC in most usages. In particular, you may notice that date +%s gives the same result as date -u +%s.
The relevant line where this is set in the shadow password utilities is"
nsp->sp_lstchg = (long) time ((time_t *) 0) / SCALE;
Which would make it UTC.
SCALE is defined as 86400 (except via a specific ifdef that I can't quite trace what circumstances cause to be defined)
--utc tells hwclock that the hardware clock keeps UTC, and --localtime says that the hardware clock keeps the same timezone as the system clock. (More precisely, it says that the hardware clock keeps the same offset to UTC as the system clock currently does — hardware clocks often don't know whether DST is active.) These options have no relation with the timezone of the system clock.
In theory, this tells you everything you need to know. In practice, this can be confusing.
# date -u; hwclock -u;
Tue Apr 9 20:08:44 UTC 2013
Tue Apr 9 15:08:45 2013 -0.397120 seconds
“First, tell me the system time in UTC. Then, assuming the hardware clock keeps UTC, what is the time in the local timezone?”
# date; hwclock --localtime
Tue Apr 9 15:09:07 CDT 2013
Tue Apr 9 20:09:08 2013 -0.686601 seconds
“First, tell me the system time in the local timezone. Then, assuming the hardware clock keeps local time, what is the time in the local timezone?”
On most systems, you can set the TZ environment variable to set the timezone for a process. It's a POSIX feature. BusyBox supports this (I don't see an option to turn it off at compile time), and I believe so does uClibc. When working on clock synchronization, it can help to operate all in UTC for a short while:
export TZ=UTC0
date
hwclock
Best Answer
You can change the timezone with smitty, the reason it wants a reboot is because services like cron are running with the old settings.
In order to avoid the reboot you would need to,
If you don't care that services are running with the wrong timezone, then you don't need to reboot the server.
As a minimum, to avoid rebooting you should kill cron and let init restart it. Other services may or may not need restarting depending on your preference and what logs you don't mind being wrong.