Hi Robert I enjoyed reading your rant, and I agree with a lot that you say, but not all. Certainly, the source file format is something that one would think that all users of the data should have the chance to comment about. I'm sure there are many people that would prefer there never be any changes at all, and others that could provide novel suggestions for enhancements. I would hope that all suggestions about the data, from all users, would be at least entertained. The needs of all users are different, and the prefered format for their needs will therefore be different. That said, of course, its up to the maintainers, knowing their users, to decide in which format the data should be released, and if that doesnt conform with the wishes of some of the users, then of course, its up to those users to find other solutions. In our case, our requirements where that we could provide updated timezone information to our users within 24 hours of being aware of them. Since we are not in charge of generating the original data, we are dependant on its releases for updates, as we all are. As well, since we do not maintain zic, we are dependant upon any changes that may need to be applied to it as well. Our solution was to write our own parser to extract the data we needed directly from the tar.gz, and put it into a format that was most appropriate for our own use, bypassing zic altogether. This removes one level of dependancy, and also gets the data into our preferred format immediately. When there is a new tar.gz released, our users can have updated data in their systems automatically by an automated ftp. The basis of our current requirements, is to provide time and date information for long-range (past and future) research . Our parsers are used in astronomy products, archo-astronomy products, as well as for genealogy and other historical research. Our time & date conversions reach back and look forward tens of thousands of years, and can generate the solar, mean and 'zone' time for any date over a 100,000 year span, as well as matching against dates in other calendars. Though its true that no one was wondering about daylight saving and zone offsets 10000 years ago, the dates we compute for 10000 years ago, give users a 'feel' for the time of an event that happened that long ago. Most people don't know the difference between apparent time and mean time, but saying that an event likely happend near 6PM EST June 1st 8000BC is something that most people can relate to. More importantly, for more recent historical research, knowing when a region generally went from solar time to local mean time, then to standard time is very useful for pinning down the accuracy and synchronicity of recorded historical events - such as eclipses. Im sure the tz database was never originally intended for this purpose, but no doubt there are others on this list that use what they can from tz, then augment it with data and algorithms from other sources. If we suggest changes to tz to make things easier for us, without interfering with the needs of current users, its because the data is now being used far beyond its originally intended purpose. As for my thoughts about changing the actual format for my own needs, i have made a few suggestions, but think most of my ideas would probably cause more grief to others than the advantage they might gain me, so most of my suggestions have remained unmentioned and are handled instead in our parsers.