I have had problems with timezones like this:

The 'date' command reported initially the 'PUP' timezone which I think comes from 'vanilla Puppy' and is probably down to BK himself. That's all fine, but I'm in the UK and wanted to run a server which is permanently set to UTC (ie. GMT).

So I investigated the /etc/TZ file. I tried setting /etc/TZ to UTC but it didn't seem to do anything. This is probably because UTC is not recognised - ie. listed in /usr/share/zoneinfo - but GMT+0 is.

So I set /etc/TZ to read 'GMT+0' and now the CMOS clock setting is reported correctly by the 'date' command.

Then there were 2 issues remaining:

1. I run cron (Vixie cron 4.1 locally compiled from source). However, the shell scripts I run from cron, report timestamped messages (simply using the 'date' command) in a separate log file. These messages were all 8 hours out.

EDIT: Old stuff removed. The correct solution is to do the following (if you're in GMT):

That fixes the cron time zone problem.

2. Some daemons that I run during startup, which were added to the /etc/rc.d/rc.services file (sshd, thttpd and others) report periodically into the /var/log/messages file. Their messages have a timestamp of 8 hours ahead, followed by the string 'GMT-8'. I think the root cause of this is that when the daemon was started in rc.local the TZ variable was undefined (blank) or perhaps still set to the 'PUP-8' value.

Perhaps the rewriting of /etc/localtime above will fix the problems after a reboot (ie. the daemons concerned are restarted). I'm not brave enough to restart them all individually, especially sshd, when working on an ssh connection!


I'll report back here as usual.
Simon.

Just a note to say I've edited out all the garbage above and replaced it with the correct solution for the cron timezone. This pops it to the top again.
Simon.

It all worked out fine after a few hours. The daemons which report occasionally in /var/log/messages all eventually picked up the correct timezone. No reboot required :-)

Simon.