The following is an excerpt from a response I recently sent to Alex Livingston followed by my response to Eric Ulevik. Since both emails to me were also sent to tz@elsie.nci.nih.gov, I felt this email to be needed. ------------------------------------------------------------------------------- You are quite right about Australia/Hobart. I took Paul Eggert's input as gospel, so to speak, and he mistakenly treated Australia/Hobart as the same as Australia/Sydney. At the risk of telling you in boring detail what you already told me, here are the appropriate pairs of rules for Australia/Hobart Rule AT 1991 max - Oct Sun>=1 2:00s 1:00 - Rule AT 1991 max - Mar lastSun 2:00s 0 - and Australia/Sydney Rule AN 1987 max - Oct lastSun 2:00s 1:00 - Rule AN 1996 max - Mar lastSun 2:00s 0 - Clearly "Sun>=1" is not the same as "lastSun". You may see an errata about this one to tz@elsie.nci.nih.gov in the not too distant future. It would have also have been clearer to append " --> None" to both rules Aus and AQ since I was concentrating on current time zones and into the future, at least for the time being. As for Indian/Cocos, it is separated from the rest of Australia in the "australasia" file, and my lack of geography knowledge means that I did not realize that it was owned by Australia. There needs to be a modification of the "australasia" file if you want it automatically collected as a time zone of Australia in my processing. I do not know who officially to notify of that to effect the change. Do you? I will be happy to make it a time zone of Australia in my personal bookkeeping right now, though. This may be another one for the errata sheet. . . . ------------------------------------------------------------------------------ I just responded to a series of comments from Alex Livingston that included the mistake with respect to Tasmania's time zone without noticing he had subsequently sent a copy of his comments to tz@elsie.nci.nih.gov and also without noticing that you made a similar set of comments. A copy of my response to Alex will be sent to tz@elsie.nci.nih.gov after I get done responding to the rest of your comments. With regard to my

planning to ignore time zones which are the same currently, but were different historically

being a mistake, it is funny that you should mention that, because Paul Eggert and I were having a similar discussion away from tz@elsie.nci.nih.gov (at least I think it was away from tz@elsie.nci.nih.gov) with me attempting to take the position you are now advocating. The problem is not in loosing geograpical information, because all that the tz database has currently in terms of lat/lon geographic information are single lat/lon points for each time locale, currently stored in "zone.tab". The problem is, or rather the problems are: (1) We need to be able to automatically process the existing tz database at any point in time in the future to get lists of what might be called "local time zones", i.e. the list of countries that only observe one time, with or without daylight savings time shifts, throughout the year, and the list of multiple time zones by country in countries where, for reasons of either standard time and/or daylight savings time observance variations, observe multiple times at one time or another throughout the year. These "local time zones" can then be combined into "regional time zones" at any point in time, where "regional time zones" are the amalgamated total of all "local time zones" whose clocks are set the same at that point in time. These lists need to be generated and compared to their previous counterparts to see if anything has changed. (2) We need to be able to conveniently respond to changes in "regional time zone" boundaries, especially if we have either previously gathered the lat/lon pairs of the boundary in question or if we have previously gathered, as I am now attempting to do, the lat/lon pairs, i.e. the digital line graph (dlg) data (properly converted to lat/lon polygon data for ease of subsequent handling) for political jurisdictions within the countries in question down to a sufficiently fine granularity that we can simply create lists of the jurisdictions associated with each of the "regional time zones" in question and automatically generate their overall boundary lat/lon polygons. With regard to

Hopefully it will be available on a web page...

Any data gathered in (2) above should be made part of the tz database and will be made available in as open a manner as is reasonable/possible. It certainly will not be thrown away. So, as the time zone boundaries change and change back, it will certainly be possible to go back to a previous boundary easily. As for web pages, there currently exist somewhat cumbersome ways to provide this capability in a secure manner (maybe with Java Applets, but totally avoiding Java Applications) on a web page, and certainly if I am able to assemble a sufficiently interesting data set, I will make it a high priority to put the needed effort, around the edges of my other work, into seeing that such a web page gets created and maintained. Furthermore, it should be possible to directly support most Unix boxes with far more efficient versions of the same capability independent of the web page interface. Finally, the automatic assessment of the current situation in (1) above certainly must deal with all of the "Zones" and all of the "Rules" that show up in the tz database. Furthermore, although I am presently focusing only on present and future "regional time zone" boundary data, this is merely to keep my immediate problem as manageable as possible. This should not be construed to mean that I am not interested in historical time zone boundary data. To the contrary, I am very interested in acquiring sufficient historical lat/lon data to make the presentation of historical time zone information by the gazetteer a reality. Unfortunately, unless there is a significant breakthrough in obtaining such historical lat/lon data, present and future time zone information is all that can be reasonably expected in the foreseeable future. Dave Skinner dave@kirdu.jpl.nasa.gov