On Wed 2011-12-07T20:37:24 +0000, Zefram hath writ:
Generally, I think your goal of being able to look up a geographical timezone based on the abbreviations it uses is a sensible one, but creating new names for the zones is not the way to go about it. The lookup should be a separate process, and should have explicit handling for abbreviations used by more than one zone. The abbreviations just don't behave like a namespace for these zones, in addition to them actually naming something other than the geographical zone.
If I am not mistaken this is one of the issues under consideration by the Timezone Technical Committee as they work out registry issues and server protocols. http://calconnect.org/tc-timezone.shtml to which I do reply: If I may suggest an approach, prior to the creation of a definitive solution, it would be to iterate through the various time zones, for each one finding the abbreviations that it can have, and thus building a lookup table from abbreviation to zone. (I imagine a key-value structure where the abbreviation is the key and either an array or a delimited list of zone names is the value, but it really depends on the language you're writing in.) Special-case handling is recommended for the abbreviation LMT, as almost every zone can have that abbreviation. Thus, for example, an input of CST would get America/Chicago, America/Winnipeg, America/Regina, Australia/Adelaide, Australia/Darwin, various minor areas in the vicinity of those, and maybe also Europe/Prague and Europe/Bratislava if "CST" was used there as the placeholder for Czechoslovakia Time (don't have that file in front of me). You would then present those to the user in whatever form you deemed appropriate.