I looked further into the problem that you mentioned with sendmail in Australia, and I think I tracked it down to a bug in the way that tz implements leap second support. Here's an instance of the problem, assuming that you installed the tz package in the default way, and that all commands run in the same second: $ TZ=right/Australia/Adelaide sh -c 'date; date -u' Sat May 23 11:14:40 CST 1998 * Sat May 23 01:45:01 UTC 1998 $ TZ=posix/Australia/Adelaide sh -c 'date; date -u' Sat May 23 11:15:01 CST 1998 Sat May 23 01:45:01 UTC 1998 The output line marked '*' is bogus: it's too large by 21 seconds, because the tz code does not adjust for leap seconds when computing gmtime, if TZ specifies leap seconds but the .../zoneinfo/GMT file does not specify leap seconds. Because of this problem, sendmail will currently report an incorrect time zone about 1/3 of the time if (1) you're in the eastern hemisphere, (2) you're using leap seconds, and (3) the system default is no leap seconds. The bug occurs with the above example time stamp, since sendmail subtracts 01:45 from 11:14 and comes up with +0929. The basic problem is that tz code looks at the system file .../zoneinfo/GMT to decide what leap seconds to use when computing GMT; this leads to bogus results if the user wants leap seconds and the system file doesn't (or vice versa). One possible fix is to have the tz code look at the leap seconds information in the file that the TZ environment variable specifies, rather than the .../zoneinfo/GMT file. This would also be a tad more efficient, since it would mean one less file to look at. Arthur David Olson is obviously the best person to evaluate this proposed fix, though. I haven't looked at the GNU C library to see whether it has the same problem.