tz leap second bug encountered by sendmail 8.8.8 in Australia
bww at fore.com
Sat May 23 04:25:34 UTC 1998
> 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).
Might I proffer that this is not a problem with the tz code, but a
truthful representation of the situation presented to it.
If "the user wants leap seconds and the system file doesn't (or vice
versa)," the user is just kidding themselves. Either the system clock
ticks leap seconds (a stationary epoch), or it doesn't. All tz files
used on the system should reflect that reality.
The suggested gmtoff() algorithm will always produce such varying
results if localtime() and gmtime() cannot agree on minute boundaries,
whether the discrepancy is a leapsecond artifact or not.
More information about the tz