time zone geography

[Chris Sells]

I don't have any particular GIS "skills," but I have plenty of database
skills and I certainly have interest (I once tried to map phone numbers to
time zones, but stopped because I couldn't find enough freely available
information). Let me know how I can help.

Chris
----- Original Message -----
From: "Olson, Arthur David (NCI)" <olsona at dc37a.nci.nih.gov>
To: "tz (E-mail)" <tz at elsie.nci.nih.gov>
Sent: Sunday, February 18, 2001 9:45 AM
Subject: FW: time zone geography


>
>
> -----Original Message-----
> From: Chuck Ellis [mailto:cellis at gaz.com]
> Sent: Friday, February 16, 2001 5:45 PM
> To: Olson, Arthur David (NCI); 'tz (E-mail)'
> Subject: time zone geography
>
>
> 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.
>
>
>