I recently downloaded tz{code,data}1997a.tar.gz in order to update our timezone database. Because we will not be using any dates earlier than 1970 I used zic -s to save space. All the timezone information was compiled, but when I tried to install the data into our database four timezones failed the sanity checks. I found that the compiled files for these timezones were each 44 bytes long and contained only zeros. The zones were: Australia/Darwin Africa/Accra Africa/Freetown Africa/Johannesburg (none of which have transitions after 1970). I looked at zic.c and made the following changes: 207% diff zic.c zic.OLD.c 3c3 < static char elsieid[] = "@(#)zic.c 7.81 +DaveS"; --- > static char elsieid[] = "@(#)zic.c 7.81"; 1572a1573 > usestart = i > 0 && (zp - 1)->z_untiltime > min_time; 1576d1576 < usestart = (timecnt == 0 && !useuntil) || (i > 0 && ((zp - 1)->z_untiltime > min_time)); which was partially successful (the Australian timezone was handled, but the African timezones needed modifications which wouldn't have been necessary if the fix had been correct: 208% diff africa africa.OLD 325,326c325 < 0:00 Ghana %s 1942 < 0:00 - WAT --- > 0:00 Ghana %s 561,562c560 < 0:00 SL WA%sT 1962 < 0:00 - WAT --- > 0:00 SL WA%sT 581,582c579 < 2:00 SA SA%sT 1944 < 2:00 - SAT --- > 2:00 SA SA%sT ). After looking more carefully at the timezone data, I realised that what the troublesome timezones had in common wasn't just that there were no transitions after 1970, but also that the last transition was by Rule. Since by then I had compiled data which we could use, I didn't look at zic.c again to try to work out a better fix. Incidentally, the assumption that the first Standard Time offset should be used for times before the first transition doesn't work well for Southern Hemisphere timezones: in many cases Summer Time will be in effect at the earliest time handled. (In case you were wondering why we need to import the timezone data into our own database: the application in question has to handle multiple timezones and is nor written in C or C++.) -- Dave Sparks, Staffordshire, England (posted from my private mailbox to avoid my employer being legally liable, since in English law a disclaimer would be ineffective.)