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. Bradley