id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
10324	Better Timezone Selection interface	Otto42		"As matt mentioned in #3962, the new timezone selection interface is not the best. It was simply the easiest, and I never intended for it to be finalized like that.

So I'm starting this ticket for ideas/implementations of better UI's. I'll start. :)

One of the ideas by sambauers in #3962 was an autocomplete type in interface. I have no real problems with that idea, it was the implementation that I disliked. Maintaining our own list of cities? Horrifying. I also didn't like that you put in a city and had to save it before you found out whether or not it would work. Even with autocomplete, you're shooting in the dark here.

My idea is to use Google and Geonames webservices to figure out the timezone via an AJAX method. Without Javascript, we can fall back to some other approach.

There's lots of possible ways to do this interface with these APIs. Geonames is capable of converting a lat/long into a valid timezone easily enough, while Google could be used to look up placenames, to display a map to click on, or even to simply make an educated guess as to where the user currently is located based on IP. If Gears is available, that location information can be made more accurate. Alternatively, the new Location awareness functionality in Firefox 3.5 could be used to figure out the current location (this functionality is identical to Gears location, as they use the same Google services).

I'm attaching a simplistic HTML/Javascript example. This example uses one of two methods to determine the users timezone. The automatic ""guess my location"" method, and the manually entered placename method. Both use jQuery and Google and Geonames webservices (via JSON callbacks).
"	enhancement	closed	low		Administration	2.8	minor	duplicate