A Timezone Gazetteer (and Map Maybe)

[Dave Skinner]

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 at 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 at 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 at 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 at 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 at elsie.nci.nih.gov
(at least I think it was away from tz at 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 at kirdu.jpl.nasa.gov