Leapseconds and zoneinfo

[Martin McCormick]

	Several months ago, I rebuild the zoneinfo data bases on
the freeBSD systems we have to be ready for the new Daylight
Saving Time or Summer time rules.  I got the leapseconds file and
the North American data base and used zic to build a new version.

	The first time I did this, I included the leapseconds
data base in to the command as in

zic -L leapseconds northamerica

	What I got was a file slightly larger than the current
version of localtime which, in the Central Time Zone is a copy of
/usr/share/zoneinfo/America/Chicago.

	I didn't think much of the difference since it is a
replacement for what was there and installed it.  The local time
was 23 seconds behind what it should be.  There have been 23
leapseconds added since 1972, I think, so I figured we didn't
need  to have them in there.  After recompiling the data base
without the leapseconds, each system's UTC seconds perfectly
matched the local time's seconds which is what is supposed to
happen.

	Then, we come to today.  I was experimenting with a
FreeBSD system and noticed that the date;date -u commands yielded
time stamps that were off by 23 seconds, but in the other
direction.  This time, I ran the command in the form you see
above, with the leapseconds, and now that system's seconds
perfectly match between UTC and Central time (CDT in Summer and
CST) in Winter.

	Why would this one system which is an old 266 MHZ Pentium
running FreeBSD 4.10 be different?  Another old Pentium running
FreeBSD4.7 needed the leapseconds removed before it gave the
correct seconds for both UTC and Central time.

	I did verify that Chicago was the same file on the odd
system as it was on all the normal ones, normal being that the
seconds are correct for both UtC and local.

	So, for some reason, about 5 FreeBSD systems work
properly without the leapseconds data base and one needed it.  Why?

	It would stand to reason that all the systems need the
leapseconds since that agrees with the rules for calculating
correct time.

	Thank you.


Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Network Operations Group