time zone geography

Chuck Ellis cellis at gaz.com
Fri Feb 16 22:45:23 UTC 2001

I have worked on the subject of time zone geography in the past (with tz's
data) and actually had gotten thru to the point of generating a low-scale (~
1:2MM) world map of the (I believe in 1998 it was 305) unique geographic
zones.  Since the zones were boundary objects in a GIS application, DST
rules were applied dynamically, so the actual unique boundary count changed
depending on date and time.

I interject myself into the list discussion at this point because geography
is simply a special case in relation to any proposed tz-focused software
application that is going to deal with it. Even the issue of whether an area
code is in a particular time zone or not is non-trivial. "Area Codes" are a
North American 'thing', specifically defined by the North American Numbering
Plan (NANP, managed by Bell).  The rest of the world uses a
Country-Code/City-Code system.  The point is relevant because the geography
of NANP boundaries is reasonably well characterized into a contiguous set of
boundary polygons, with some "overlays" of identical boundaries where such
overlays exist.  Therefore, what particular zone(s) are relevant to a time
zone in the NANP system is a matter of quite precise geographic calculation:
one overlays the area code boundary map onto the time zone boundary map, and
reads back the relevant "object contains" and/or "object intersects" set of
time zones. Perfectly likely that a NANP area code completely contains one
tz (e.g., Indianapolis is the summer), and intersects in some proportion
another (e.g., Chicago).

In the rest of the world, it can get quite messy.  City-Code boundaries are
well-characterized in some countries (e.g., France), and utterly nonexistent
in many more (e.g., Burundi). The best one will be able to do in these
situations is to default to using a "centroid" (the approximate geographic
center of a city or town) and simply reading back which tz those coordinates
fall within.

The larger issue is not, of course, area codes, but any geography.  It's a
long list, but is best organized into three natural classes of geometric
objects-- points, lines (including polylines), and polygons (including
closed curves). The most relevant polygons include political, civil,
administrative, telcomm, marketing, cadastral (property), statistical, media
and those from the natural sciences.  Common examples are country/state,
city, area code, Designated Marketing Area, broadcast signal surfaces,
lakes, zip codes, etc. Line and polyline objects can include roads, rivers
(depending on resolution and scale), rail, power and fence line, pipeline,
faultline and many more.  Point objects are even more numerous, but
certainly start with a "gazeteer", or roster of city/town names and
coordinates, and progress to physical objects (towers, buildings, wells,
etc.) to the very spot you happen to be sitting at right now.

It is reasonable to imagine almost any type of geographical object, and want
to know-- "What time zone is it in ?"

Any application that is going to answer this question does not need to
reinvent the wheel and write code to analyze overlaps, intersections,
contains or any other "standard" GIS (geographical information system)
function, including simply rendering and printing.  There are hundreds of
GIS systems out there, and even more code tools to embed particular
functions into "your" app.

The real challenge is on two ends of the issue-- the time zone "map", such
as needs to be created and maintained; and the "map" (or at least digital
embodiment therein) of whatever geographic object(s) are to be compared
against the time zone map.  For example, to determine what time zone(s) a
particular NANP area code lies in, we need a digital map of that area code,
the digital map of the world's time zones, and any GIS software or
application containing such functions.  Digital maps of nearly everything
and everywhere are pretty widely available.  Most addresses can be quickly
"geocoded", or assigned lat/lon coordinates-- which is a digital map of that
address. Since almost any geographical object's map can be purchased or
downloaded with relative ease (cost notwithstanding), the map that is
missing is, of course, a current time zone map.

As I have pointed out in this discussion some years ago, a complete and
current time zone map holds enormous power and utility for many (if not
most) of the readers of this discussion list. One can purchase the GNIS
CD-ROM containing the official names and coordinates of over 4 million
cities, towns, villages, places, etc. in the world; overlay this file on a
world time zone map; and in approximately 2 to 3 minutes on a Pentium PC,
assign the proper time zone to all 4 million places. It's a little more
complicated with boundary (polygon) overlays, but you get the idea.

I am willing to devote some more time to trying to create the fundamental tz
map that is needed for the generalized application that Arthur is
discussing, but it is too much for one person alone, and really requires an
organized effort to maintain its currency against the ever-changing tz
database. I would ask at this time if there are any volunteers out there
with some GIS or database skill that would help, and if there are enough
responses, perhaps we could proceed to a more permanent group of focused
volunteers.  Initially, we would not tackle historical zones-- the current
stuff is hard enough to keep track of !

Chuck Ellis
chuck_ellis at msn.com

-----Original Message-----
From: Olson, Arthur David (NCI) [mailto:olsona at dc37a.nci.nih.gov]
Sent: Friday, February 16, 2001 3:48 PM
To: tz (E-mail)
Subject: RE: What is a time zone?

The existing public-domain time zone stuff lets you know how to represent
local time if you provide the identity of the set of rules that apply.
Recent mail has dealt with the matter of handling things such as geographic
locations or phone system area codes.

My sense is that layered software is the way to go. The bottom level turns a
time-zone identifier 
into a representation of the rules that apply. Built on top of this are
packages that take different forms of input (phone system area code,
geographic location) and deliver up time-zone identifiers. The existing
time-zone stuff is a bottom level. And there might be multiple higher
levels--for example:
	topmost	geographic location to phone system area code
	middle	phone system area code to time zone identifier
	bottom	time-zone identifier to rules that apply
The organization of the higher levels would, of course, be immaterial to
what goes on at the bottom level.

A consideration in determining the time-zone identifiers to use in such a
setup is the independent usability of the bottom level. The existing time
zone stuff uses identifiers of the form big-geographic-region/city; this
allows some meaningful applications (such as setting the local time to be
used on a computer) without recourse to a higher level (proof by existence).
There are other considerations as well (technological, political,
technological, astrological...). And determining what to use as a time-zone
identifier ought not be done in a vacuum: if the same identifier can be used
for other purposes, we've simplified our lives.

More information about the tz mailing list