Ok, we have scripts here that run our Point of Sale system for our stores that pull the date from the 'date' command in Linux as well as SQL statements that use the sysdate() function. Now, for some odd reason for the stores on the East Coast the sysdate(), the 'date' and 'hwclock' commands, and the crontabs on the system are all off from eachother. The 'date' and 'hwclock' commands return the correct time, sysdate() returns current PST time (three hours behind), some crontab's run three hours late (i.e. it is set to run at 7am EST, and it runs at 10am EST). Also, the daytime service from one machine to another (phyisically in the same place) returns PST time, even though the timezone is set to EST on both machines.

Now I've checked everything I can think of: /etc/localtime link, TZ environment variable, hwclock, date, etc.

Anyone have any ideas? It's giving me a headache. Thanks in advance.

If you're sure /etc/localtime is set correctly and there are no bogus TZs set anywhere, try rebooting. It's the only real way to redistribute the correct time zone to all of your processes.

Yep, that's what it was. I couldn't reboot at the time because the store was still open. I planned to try a reboot as soon as they were closed to see if it had any effect. I think just restarting mysql, xinetd (for the daytime service), and crond would have done it as well.

If those processes were the only ones whose time zones you cared about, then, yeah, you could have done that. The real problem comes from those processes that you can't restart and that are children of those processes. These are mostly the stuff in inittab and login processes. ISTR that the Linux kernel does something with timezones, too (though I can't think what that could possibly be), and I have no idea how to deal with that.