ICal Timezone Selection and Naming

Question

A few OS revisions past timezones were named with some at times distant association to UTC standards and could be attached to an event. Type in Eastern Standard or just Eastern and up came timezones with that in their name. Simple right, if you knew the name of the timezone you were planning the event for? Seems reasonable, if you are scheduling events for different time zones you might, nay probably, knew the name of the timezone. Or could easily find it online.
As I recall you could also type the name of a city like Cleveland or Stockton, or even some more obscure places like Vienna or Paris, and get the same results.
Apple changed it, to remove any confusing references to actual standard timezone names when selecting, ahem, a timezone. Nor can you select by offset from UTC (0) known to most as GMT, which was also an available choice.
One currently has to name a city or large town that Apple has deemed worthy of inclusion, and while shock of shocks the US database of cities, towns and hamlets is fairly well populated, those outside the US  appear to have been selected by a bored intern who snuck a bottle of beer in armed with a dart and a word map.
Requiring one examine, from an example I prepared earlier, the map of Western Australia searching for a town that appears significant enough to perhaps have been included in said timezone popup menu by Apple that is also located near Grass Patch (look it up), and hopefully happens to be in the same timezone is an exercise in almost random guesswork. Take a look at a timezone map of Australia if you think they are all stacked neatly side-by-side with borders as straight and dull as a Texas town main street.
I own a computer to avoid error inducing, repetitive, dull activities that could better be done by a well trained pidgeon. It is, obviously I suppose, very irritating and ironic that it was a desire to avoid such errors that was the reason one turned on timezone support in the first place.
You also have to know in advance, or try possibilities at random, the name town or city hoping that it appears in the Apple town-or-city-name-apparently-chosen-at-f*****g-random-and-associated-with-a-tim ezone popup menu in your effort to select the same timezone as your event attendee. Proximity does not guarantee a town is the same timezone after all. Often a distant town or city in the Apple popup will be in the same timezone, while one nearby is not. But you cannot know for certain without trawling through the internet and wikpedia to work this out because most maps do not include delineations of the various timezones.
In this case Apple has made a mistake in deciding what not to do. Removing a perfectly usable, well not perfectly but better than this, existing system in place as an option was an error.
By removing standard UTC codes, or something approximating them (you know the international standard naming convention for timezones that has been abandoned in an application trumpeting its adoption of standards), instead of just leaving them available alongside the calendrical equivalent of Soma, may, may, have made the system easier for people unfamiliar with timezones. But I doubt it, it is more likely to guarantee continued ignorance based on increased confusion engendered by use of a system providing no pattern or framework for understanding the concept of timezones, and it is a pain in the rear for anyone else.
It also is part of a trend previously only inflicted on Windows users routinely of attempting to make things simpler for more people while making it impossible or more difficult to someone who knows what they are doing. I have no objection to providing simpler alternatives, just stop taking away more elegant if intellectually "demanding" ones already in existence.
Looking up what city is nearby in the hope it is on the magic list for every one horse town a client might live in instead of just being able to type one of the Australian UTC standard timezones as provided by the client, or pick an offset of +8 hours in the above example is patronising, absurd, time consuming, and prone to errors.
Is there anyway I can use the terminal to edit the pop up list of time zones or substitute a different one referenced by iCal? Or to restore something resembling a standard pop up list ordered by offset from UTC 0, otherwise known as GMT? If I could simply pick an offset of -8, or +5 hours, as examples, life would be a lot happier in iCal. Because even if I have to determine some offsets, as in the WA example above, doing so is as simple as typing "What is the time in <insert name of obscure s******e here> <name of country here> in my browser bar and hitting Enter.
Yes I know that means I may have to do addition or subtraction, but I have the Apple Calculator for anything over 2, and somehow it has been spared any attempts to simplify its use.

Answer 1

I've had this same issue 2 times now (I'm also on the same setup as you).
What has worked for me is the workaround listed here:
http://www.macosxhints.com/article.php?story=20070313180838582
To simplify, copy the script shown in the last post into a text file called:
correctBirthdays (no file extension such as .txt is necessary)
and save it into your home directory. Once you've done that:
1. Back up your Address Book with the 'File > Back up Address Book...' menu item
2. Open the Terminal application
3. In Terminal, type *chmod 755 correctBirthdays* to make the script executable.
4. Type *./correctBirthdays -1* and hit enter. If you're coming back from Japan, you'll want to use 1 instead of -1 to move the birthdays forward instead of back a day.
5. That's it. Terminal will report how many birthdays were corrected.
I'm guessing that this problem has been fixed in Mac OS X 10.5 Leopard, and that's why musicale can't reproduce the issue.
Hope this helps!
(and I take no responsibility if you mess something up! It should work though.)
Rafael