There appears to be a bug in zic when leapseconds are provided, for any time zone transition near a leapsecond. The bug is that after reading in the Leaps as Posix seconds in the trans[] array, adjleap() is called. This converts these to genuine UTC seconds. However, this array is then used to fixup transition times which are in posix seconds, by for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) if (ats[i] >= trans[j]) { ats[i] = tadd(ats[i], corr[j]); break; } } ats[] is stored in posix seconds, but trans[] is in leap seconds. The effect is that for Europe/London, the transition on 1996-01-01 00:00:00 is actually set to be at 1995-12-31 23:59:60, i.e. on the leap second (820454419). Any transition in the range 1996-01-01 00:00:00 to 00:00:18 is similarly off by one second. The fix is obvious in principle (have a copy of trans[] that isn't leap-second adjusted, and use that in the code above), but not all the uses of trans[] in the code are obvious to me (what are Rolling leapsecs?). I'd also suggest that zic reject any transition in its input with a second=60. It's usually run without a leap file so there's no point in implementing the correct behaviour for that case. Many thanks, David Robinson