On Tue, 06 Dec 2011, Steven Abner wrote:
I could use some input. I have a different database, lots of reasons for it, which has the attached file as part of the database.
You didn't explain what you were trying to do, so I had to figure it out from the file attachment. Let me try to explain it for others. If I have correctly interpreted your intention, you want to make it easy for software to interpret time zone abbreviations in user input, and to that end you suggest making a lot of abbreviation-based time zones to supplement the existing location-based time zones. Essentially, for each abbreviation that appears in the existing location-based time zone data, you would create another time zone whose name is based on the abbreviation and whose definition is a link to the location, and you would have some sort of method for resolving conflicts where the same abbreviation is used by multiple time zones. You would also add some other abbreviations with other simple definitions, such as the "military" time zones A to Z. For example, given the existing definition of Pacific/Chuuk: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Chuuk 10:07:08 - LMT 1901 10:00 - CHUT # Chuuk Time and given that the abbreviation "CHUT" is unique, you would add this link: Link Pacific/Chuuk Abbr/CHUT Once you have this, software that receives the string "CHUT" in a context where a time zone name would be appropriate, can try using the "Abbr/CHUT" time zone to make sense of it. This seems fairly useful to me, despite the obvious problems with non-unique abbreviations. --apb (Alan Barrett)