On Sat, Aug 18, 2012 at 1:27 PM, Karen Etheridge <[email protected]> wrote: > > On Sat, Aug 18, 2012 at 12:00:33AM -0400, Ted Byers wrote: > > The most obvious reason is that there are a great many more cities in this > > world than are named in the basic timezone. Such a service is essential if > > you want to support determination of the proper timezone from, e.g., a > > mailing address. Given that is seems so obvious to me, it is a wonder that > > someone hasn't alreay written a package that bridges the gap between > > geo-coding and the timezone database; but maybe one wouldn't be too hard > > built on something like the geonames database. > > I would certainly find it useful for there to be a module that, say, > answered the question "what is the timezone in city X", with support for > all cities in the world of population over, say, half a million people, > and potentially added (dynamic?) aliases to the canonical timezone. > > (After all, my timezone, UTC-0800 (winter), UTC-0700 (summer) has many > representations in the olson db which (as far as I know) are currently > identical - America/Vancouver, America/Whitehorse, America/Dawson, > America/Tijuana, and America/Los_Angeles.) >
I am presently looking at a few perl packages that should facilitate developing such a package (which I will do in due course if no-one identifies one that already exists - I haven't found one). The packages I am looking at are: Geo::GeoNames Geo::GeoNames::File Geo::Query::LatLong Geo::Location::TimeZone I figure the first two provide for two different ways to use the geonames data. The first uses the geoNames web services (and requires you to sign up for an account - I do not know how long that will continue to be available without cost), and the second provides a way to use the same data from one of their data files that you have downloaded to your own system. I see the second two being a fallback solution if the city in question is not in the geonames database. Geo::Query::LatLong lets you get the latitude and longitude of a city and Geo::Location::TimeZone gives you the timezone for a given position sepcified by latitude and longitude. This strikes me as more sensible, and almost certainly faster, than trying to find the city in the oslen db that is closest to the city for which you want the timezone. The overall logic would be to first see if the city for which you want a timezone is inthe olsen DB. If not, check geonames, and if that fails, use the latitude and longitude of the city to get a timezone. I am also looking at loading the GeoNames data into my databases (Postgresql and MySQL), and accessing that directly instead of accessing it from a text file: this would be to determine which is faster. One of the tasks I suppose I will have to do is check to see how many of the timezones in these other sources are incompatible with those in the Olsen DB, and then find a mapping of them to the olsen timezones. But, while I would be prepared to share the resulting code, if and when I decide to implement something, I am not prepared at this time to deal with having to maintain it in any kind of repository. If you need this, you may want to look at the above packages and logic with a view to rolling your own package. Cheers, Ted
