FW: zic leapseconds bug

[Olson, Arthur David (NIH/NCI) [E]]

David Robinson is not on the time zone mailing list; direct replies
appropriately.

				--ado 

-----Original Message-----
From: David Robinson [mailto:drtr at apache.org] 
Sent: Tuesday, June 13, 2006 11:07 AM
To: tz at lecserver.nci.nih.gov
Subject: zic leapseconds bug

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