time zone geography
csells at sellsbrothers.com
Sun Feb 18 20:15:08 UTC 2001
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.
----- 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
> depending on date and time.
> I interject myself into the list discussion at this point because
> 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
> code is in a particular time zone or not is non-trivial. "Area Codes" are
> North American 'thing', specifically defined by the North American
> Plan (NANP, managed by Bell). The rest of the world uses a
> Country-Code/City-Code system. The point is relevant because the
> of NANP boundaries is reasonably well characterized into a contiguous set
> 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
> one overlays the area code boundary map onto the time zone boundary map,
> reads back the relevant "object contains" and/or "object intersects" set
> 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
> well-characterized in some countries (e.g., France), and utterly
> 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
> 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,
> 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
> 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
> 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
> 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
> map that is needed for the generalized application that Arthur is
> discussing, but it is too much for one person alone, and really requires
> 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
> locations or phone system area codes.
> My sense is that layered software is the way to go. The bottom level turns
> 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
> There are other considerations as well (technological, political,
> technological, astrological...). And determining what to use as a
> identifier ought not be done in a vacuum: if the same identifier can be
> for other purposes, we've simplified our lives.
More information about the tz