tz leap second bug encountered by sendmail 8.8.8 in Australia

Paul Eggert eggert at
Sat May 23 01:43:43 UTC 1998

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

    $ 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,

I haven't looked at the GNU C library to see whether it has the same problem.

More information about the tz mailing list