On Sun, Aug 19, 2012 at 12:26 AM, Jim Monty <[email protected]> wrote:
> Ted Byers wrote: > > 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). > > Existing Geo and DateTime Perl modules will do what you said you needed > done: look up time zones by city names and then use those time zones in > date and time computations. There's no need to write a new module. > > That depends on how many places in your application, and how many applications you develop, you need this kind of functionality. Granted, the module may be relatively simple, but it would be useful to provide a single function call, for a client application, and have that function look at each option in turn. > > 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 in the Olson DB. If not, check geonames, and if that fails, > > use the latitude and longitude of the city to get a timezone. > > The Olson tz database (now, properly, the IANA Time Zone Database) is a > database of time zones, not a database of cities. The uniform convention > designed by Paul Eggert to name time zones in the database typically > includes the name of a representative city within the region defined by > the time zone. So which city within the region is used in the name of the > time zone? The Wikipedia article titled "tz database" explains: > > Usually the most populous city in a region is chosen to represent the > entire time zone, although other cities may be selected if they are > more widely known or result in a less ambiguous name. ... The location > selected is representative for the entire area. > > http://en.wikipedia.org/wiki/Tz_database#Location > > I am aware of this, and since the convention for naming the timezones involves the largest city, or small collection of cities, it is something that can be examined to see if the city for which you need a timezone is among these. If it isn't, then it is necessary to look at a db that relates city names to timezones. And since such a database is unlikely to include every municipality on the planet, then it is rational to look at use of a latitude and longitude base option. > Yitzchak Scott-Thoennes explained this in a reply to your datetime mailing > list inquiry about this same topic in August 2009. He wrote: > > Within each zone, the most "recognizable" city is used as the name. > In some cases, this isn't the largest. See the comments in the region > files for rationales. > > http://www.nntp.perl.org/group/perl.datetime/2009/08/msg7333.html > > This I had forgotten. > > 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. > > Consider SQLite. There's an existing module named > Geo::GeoNames::DB::SQLite. > > I noticed, but hadn't examined it closely as I haven't used SQLite, and I am normally using either Postgresql or MySQL. > > One of the tasks I suppose I will have to do is check to see how many of > > the time zones in these other sources are incompatible with those in the > > Olson DB, and then find a mapping of them to the Olson timezones. > > All you need to determine which time zone a city is in is a database of > of time zones by location. The GeoNames geographical database is just such > a database. It uses the Olson tz database time zones and time zone names. > There are no "incompatible" time zones in the GeoNames database. > > One of thee things I was looking for ws just such a database, and is why I was looking at geonames in particular. I didn't know, though, that they used the Olson tz database timezones. That is good to know. Thanks. But there remains the question of possibly incompatible timezone names as the author of the location packeg, that gives timezone as a function of latitude and longitude wrote in his documentation that he used posix timezones and that some of these might be usable in the datetime timezone packages. He implied, therefore, that some may not be. > I wrote a small proof-of-concept Perl script using Geo::GeoNames and > DateTime to demonstrate how to look up time zones by city names and then > use those time zones to instantiate DateTime objects. > > Thanks, this is especially useful and well appreciated.. Thanks Ted
