Terran Atlas (tm)
...the new standard in astrology softwareTerran Atlas Introduction
The Terran Atlas database now has over 13 million records of city, latitude and longitude information for 250 countries, making it the largest database in the field. It has taken a step in the direction of Google Maps by differentiating between places of different types. You can still type in the name of a city such as "San Francisco, California" or if you aren't sure of the spelling you can place an asterisk in the place name; but place names can be of mountains, lakes, schools, streams, deserts, forests, post offices, hotels, restaurants, churches, parks, dams, hospitals, cemeteries and so on. There are about 700 of these location type definitions included in the Terran Atlas. In the rare event that you can't find your location in the database, you can add it to the database, edit locations and delete as well. The Terran Atlas is a combination of 3 databases; the Geonames database, the Maxmind database and a personal database which I have been working on, all edited to fit the same format. There is a fair amount of overlap between these databases, so the actual number of unique locations is probably in the range of 8 - 10 million. The reason for this is that some locations go by different names or have different spellings for the same location. Even special characters such as the umlaut are included in these spellings. What makes this database unique is the combination of locations and time zone information which can be used for astronomical purposes. For this, I have decided to go with the Olson time zone standard (instituted by Arthur David Olson) in the Terran Atlas which will be explained below. The location data follows the ISO-3166 standard for country names and abbreviations. For state or province names it follows ISO-3166-2 rules (US, Canada), or the FIPS 10-4 standard (international).
After extensive research into the history of time keeping and after consulting with the Olson tz_database community, I've discovered that the ACS Atlas is not as accurate as I once thought. The Olson time zone community has scrutinized the work of ACS without a vested interest in the field of astrology, using the data for UNIX server synchronization, historical purposes, etc... They have spotted thousands of errors in the ACS data, but I believe that an accuracy problem exists in all astrology software due to the nature of time change information. I will address the issue of accuracy below and what can be done about it. Since then, I decided that it was important that I write my own atlas. I expected that this would be an enormous undertaking, but as it turned out the location data was the easiest to set up. The database of city, latitude and longitude information for version 1.0 was originally formatted by database programmer Paul Hysen. From these files, I was able to create a binary format for local machines which is more compact.
The Olson Time Zone Database Standard
One of the most difficult problems to overcome in constructing an accurate chart is correctly knowing the standard that a time was recorded in. Such questions as "what is the standard correction from UTC?" and "when was daylight savings time implemented?" (if at all) need to be asked and accounted for in code. In the era of computers one might normally expect nearly 100% accuracy of time zone data. For the current era this is closer to the truth, but for periods more than 4 decades into the past, the lack of historical records and a disorganized system of applying rules based upon shifting political agendas makes the data much more error prone. The history of time keeping is extremely chaotic and one of the greatest problems is that many of the rules for when a time zone or summer time was observed were never properly documented! This was the most surprising part of my work on this database: in discovering the dirty little secret of just how inaccurate the history of time keeping was: it is "hit or miss". After reading all of the comments in the Olson Time Zone database, I decided I needed to let the user know where potential discrepancies lie in the data by adding a custom memo which slides out so that users can make a judgement call and override the existing time zone setting if desired.
What are the advantages to the Olson standard?
In the past, the industry standard (ACS) was maintained by a handful of people and the data was proprietary. They worked for years researching newspapers and various journals to get the raw data to construct the atlas which was an extremely difficult and tedious task. Quite frankly, it was probably a task that should have had a larger number of people overseeing the construction of the database because it is just not humanly possible to catch all the errors in data of this size without significant manpower. Arthur David Olson says that it is a good source of data but with numerous errors. Similar comments are made by members of the Olson time zone database community. Because the Olson database has been in the public domain since 1986, there are hundreds of people scrutinizing the data through the time zone mailing list which issues updates from all over the world. It is commonly in use in UNIX / Linux servers throughout the world, Microsoft.NET API, Oracle, Sun Microsystems, IBM, HP, and the BSDs (Apple/Mac OSX, Juniper, Isilon/EMC), etc. In the comments area of the Olson data, there are numerous citations where corrections have been made in the Olson database superceding Shanks and Pottenger's data and the work of various other sources. It is important to have as many eyes on data like this as possible because with more eyes, more errors will be spotted. An atlas of time zone info that is maintained by small astrological companies without the oversight of the larger community is bound to be more error prone. This is one of the reasons why I have settled upon the Olson standard, because that oversight is already there in the tz_database community.
There are several sources of time zone information worldwide but the main ones that are used in the Olson data are: Edward W. Whitman, World Time Differences, Whitman Publishing Co, 2 Niagara Av, Ealing, London, also Thomas G. Shanks and Rique Pottenger, The International Atlas, San Diego: ACS Publications, Inc., and the International Air Transport Association's Standard Schedules Information Manual (IATA SSIM). This last one has been very useful for corroborating time change information and exposing errors (the airline industry has been in the business of time recording to maintain flight schedules across time zones in different countries). Because of this corroboration of sources, I believe that the Olson standard is the most accurate time zone standard in the world for dates after Jan 1, 1970. For periods prior to this date, the accuracy is still in question for all data sources which will be explained in a bit.
The time change history in the Olson database goes back as far as 1835 and records the onset of standard time (and the last observed LMT - Local Mean Time) in hundreds of locations in the world. It also has about 550 zones defined, each with their own time change history and rules for daylight savings and in many cases various UTC offsets depending upon the period of observance. The daylight savings / summer time observance records in the Olson data go back into the early 1900's. Zone names follow "Continent/City" such as "America/Denver" and "Europe/Madrid"... This makes the localities of these zones more robust in the face of name changes to countries and it is also more readable.
How accurate is time zone data from various sources?
This is hard to say for sure because you don't know what you don't know ("hit or miss"). It is also the case that accuracy is higher for modern times than for times several decades into the past due to technological synchronization, air transportation schedules, etc. However, having read all the comments in the Olson time zone database, as a guess, I find it hard to believe that any atlas has an overall accuracy greater than 95% at the current time (and that includes the atlases in Solar Fire, Kepler, Sirius, Winstar, etc). When you take into account standard time that is several decades into the past (between 1880 and 1970 in the USA), the accuracy level is probably below 90%, which means that more than 1 in 10 charts will be off by about 15 degrees on the ascendant in these cases. This may be shocking to some, but I didn't come to this conclusion lightly. Download the Olson database for yourself and read the comments in the files named after the continents in tzdata2010o.tar.gz (or subsequently named files). You will find the Olson database community has scrutinized the work of ACS very thoroughly in these comments and pointed out errors as well as times when the ACS data is thought to be more accurate. The reason lies not in any level of incompetency by ACS, but in the lack of manpower and in the nature of time change information itself.
Any serious astrologer should get used to the idea of rectification because there is no software in the world with 100% or even 99% accuracy in covering the whole span of standard time. It is just not possible because time change histories prior to 1970 become increasingly obscure and there wasn't an organized system of recording this data. Because of this, the original sources often came from newspapers world wide. What would you guess would be the chance that some time announcement from 1926 in Obscure Town, USA got missed, misread or mis-typed on page B-4, or worse yet some obscure town in Tibet? This is what I mean by "hit or miss". To get maximum accuracy, you would have to read every newspaper, journal or government decree (in every language) that was ever printed from every town in the world since the beginning of standard time in the early-mid 1800's. This is clearly an impossible task for a handful of people! Once you read the comments in the Olson database you will see why. As if that wasn't enough, it is also the case that sometimes localities do not follow official rules! I got to experience this first hand by accident: in late 2009 - early 2010, I was camping in Vidal, CA. The nearest town is to the east (Parker, AZ) and I noticed that Vidal is on Arizona time (Mountain Standard Time), but because Vidal is in California, it was assigned Pacific time by the ACS Atlas which is not correct. The people who live in Vidal are on AZ time because they work in Parker, AZ just 15 miles away and want to keep their clocks synchronized to their work schedule. Also in Arizona the Navajo tribes in the four corners area observe DST against official AZ rules because neighboring tribes in CO, NM and UT do so. In Nunavut Canada, 3 different time standards were observed in the same town and each business had it's own time standard depending upon the industry! In China there is 1 official time zone currently, but again there are exceptions. From the "Asia" file:
Ethnic Uyghurs, who make up about half the population of Xinjiang, typically use "Xinjiang time" which is two hours behind Beijing time, or UTC +0600. The government of the Xinjiang Uyghur Autonomous Region, (XAUR, or just Xinjiang for short) as well as local governments such as the Urumqi city government use both times in publications, referring to what is popularly called Xinjiang time as "Urumqi time." When Uyghurs make an appointment in the Uyghur language they almost invariably use Xinjiang time.
If I added every exception from the comments in the Olson TZ data here it would take too long for your web browser to load. The exception is often the rule when it comes to time zone observances.
Potential drawbacks to the Olson data
The data before 1970 aims to be accurate for the city identifying the region, but is not necessarily correct for the entire region prior to that date. This is because new regions are created only as required to distinguish clocks since 1970. The reason for the Jan 1, 1970 date is based upon the UNIX epoch in which time standards were becoming more organized through technology. Prior decades are in a more questionable area of world time zone history where discrepancies and contradictions in the data from various sources become increasingly common the farther back you go in time. Adding more exceptions to the data without letting the user know that this has been done will not necessarily increase accuracy because of the "hit or miss" problem I described above. It is also a situation where a whole lot more work needs to be done with a modest increase in accuracy. It is of course important to have as much data as possible going into the past, but it is best not to give a false impression of data accuracy in the process, which is why the Terran Atlas highlights questionable data with a slide out memo with notes from the Olson time zone database. Other atlases in the field have attempted to cover these exceptions, selecting one time standard over others without certainty, even when there are contradictions which ends up white-washing the accuracy problem. In these cases it is better to inform the user so that a judgement call can be made. Like the "Rodden Rating" which is a well known standard of grading the accuracy of birth chart information; the accuracy of time change information should be subjected to a similar standard.
What can be done to ensure chart accuracy?
Well, first of all, I have included the comments from the Olson tz_database where applicable, so that you can see the various issues that arise about the accuracy of the data for the location you type in and for the time you are setting up for your charts. The Terran Atlas is the only atlas in the world that highlights time change data that is questionable. The window will show as a popup after a lookup request has been submitted to the database if there are messages to be found. This doesn't mean that if the window doesn't show, that you are guaranteed an accurate chart. It just means that the data are in agreement or there was only one source. When the window does show, this will be an aid to rectification so that you can make a judgement call as to which time standard to use. I personally recommend that astrologers get used to asking what time standard that a birth time was recorded in because in many areas of the world, there is simultaneous observance of more than one time standard in the same location at the same time!
What can be expected in the future?
Since the lawsuit against the Olson time zone database has been dropped, the community has come back together under the direction of ICANN / IANA and is getting better organized. Alois Triendl has expressed an interest to expand the history of the Olson time zone database to complete entries for remaining areas of the globe before 1970 and make it open source. He states:
"I am also involved in the free and open tz database project, started by Olson, the defendant in this lawsuit. My particular goal is to complete the gaps this database has in some areas for some periods of history. It currently gives correct timezone information for about 90% of charts, and it needs to be completed, by gathering more historical fact information from all available sources."
There are several others currently working on this as well. Since this kind of project is too vast to be undertaken by a small group or a single person and is by nature public information, I am glad that a team collaboration exists and will support any future effort to expand the Olson database.
Terran Atlas Updates
Registered users can log in and download the Terran Atlas from the registered users area of this website. I have compressed the file to 148 MB for the install file. This includes a stand alone application for editing the database which is not really necessary, but you will need to install this file because it contains the binary data on countries and time zones that Delphic Oracle and Timaeus use. The Terran Atlas interface however has been made a part of these programs, so it is not really necessary to run the exe file to get data from the location database. Since the Olson data is maintained by the Olson tz_database community it is a simple matter to update as new zone rules and geographic / political changes are implemented.
- Curtis Manwaring
