FAQ
I looked and couldn't find any names of Indian cities that I recognized:
Dehli, New Dehli, Mumbai, Kolkata Bangalore, Madras, Chandigarh, Amritsar,
&c., &c., &c. None of the timezones I found beginning with "Indian/" are
actually in India.

I have built an infrastructure for a web application that makes extensive
use of Datetime, and especially the Timezone module, so I now I have a
problem in that my colleague pointed out to me he couldn't find any Indian
timezone data. But we now have clients in India and we have to support
them (and that means that my system for handling timezones is broken unless
I find a solution to properly support Indian timezones - i don't know - is
there more than one Indian timezone). How do I do that without breaking,
or having to spend a lot of time finding a replacement for, my use of
Datetime::Timezone?

So, are Indian timezones supported, using a name I am not aware of, or is
there a way to add support for Indian timezones without breaking anything?

Thanks

Ted

Search Discussions

  • Jim Monty at Aug 17, 2012 at 4:24 pm

    Ted wrote:
    I looked and couldn't find any names of Indian cities that I recognized:
    Dehli, New Dehli, Mumbai, Kolkata Bangalore, Madras, Chandigarh, Amritsar,
    &c., &c., &c.  None of the timezones I found beginning with "Indian/" are
    actually in India.
    So, are Indian timezones supported, using a name I am not aware of, or is
    there a way to add support for Indian timezones without breaking anything?
    Yes, of course India is represented in the tz database. It's Asia/Kolkata.
    See http://en.wikipedia.org/wiki/Asia/Kolkata.

    For a convenient list of all the time zones in the tz database, see
    http://en.wikipedia.org/wiki/List_of_tz_database_time_zones.

    For everything you ever wanted to know about time and time zones in India,
    start with http://en.wikipedia.org/wiki/Time_in_India. This article states
    "The IANA time zone database contains only
    one zone, namely Asia/Kolkata."

    Read all about the tz database itself in the Wikipedia article
    http://en.wikipedia.org/wiki/Tz_database. The Perl DateTime module
    DateTime::TimeZone uses the tz database.

    Jim Monty
  • Ted Byers at Aug 17, 2012 at 5:17 pm
    Thanks Jim,
    On Fri, Aug 17, 2012 at 12:24 PM, Jim Monty wrote:

    Ted wrote:
    I looked and couldn't find any names of Indian cities that I recognized:
    Dehli, New Dehli, Mumbai, Kolkata Bangalore, Madras, Chandigarh, Amritsar,
    &c., &c., &c. None of the timezones I found beginning with "Indian/" are
    actually in India.
    So, are Indian timezones supported, using a name I am not aware of, or is
    there a way to add support for Indian timezones without breaking
    anything?

    Yes, of course India is represented in the tz database. It's Asia/Kolkata.
    See http://en.wikipedia.org/wiki/Asia/Kolkata.

    And here I was looking for Indian/Kolhata
    For a convenient list of all the time zones in the tz database, see
    http://en.wikipedia.org/wiki/List_of_tz_database_time_zones.

    Given that it seems the entries are generaly 'continent/city',is there
    something in Datetime that will take any city or state and lookup the entry
    for the closest city? Or is that something I'll have to write, based on
    lat/lon data for cities (I am pretty sure I saw a database with lat/lon
    data for cities somewhere, but ... if it already exists, I don't have to
    write it)?

    For everything you ever wanted to know about time and time zones in India,
    start with http://en.wikipedia.org/wiki/Time_in_India. This article states
    "The IANA time zone database contains only
    one zone, namely Asia/Kolkata."

    Read all about the tz database itself in the Wikipedia article
    http://en.wikipedia.org/wiki/Tz_database. The Perl DateTime module
    DateTime::TimeZone uses the tz database.

    Jim Monty
    Thanks again.

    Ted.
  • Jim Monty at Aug 18, 2012 at 3:10 am

    Ted wrote:
    Jim wrote:
    For a convenient list of all the time zones in the tz database, see
    http://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
    Given that it seems the entries are generaly 'continent/city', is there
    something in DateTime that will take any city or state and lookup the entry
    for the closest city? Or is that something I'll have to write, based on
    lat/lon data for cities (I am pretty sure I saw a database with lat/lon
    data for cities somewhere, but ... if it already exists, I don't have to
    write it)?
    There aren't any geocoding modules in the Perl DateTime suite (why would
    there be?), but there *are* plenty of geocoding Perl CPAN modules. Check out
    the Geo::Coder::* modules, for example.

    If you want to roll your own simple time zone aliases, check out
    DateTime::TimeZone::Alias:


    http://search.cpan.org/dist/DateTime-TimeZone-Alias/

    The simplest DIY solution is a lookup table using a hash.

    If you want to do something more elaborate, there are oodles of
    geocoding resources for programmers on the web:


    http://en.wikipedia.org/wiki/Geocoding
    http://askgeo.com/
    http://askgeo.com/database/TimeZone

    http://www.geonames.org/export/web-services.html#timezone
    http://stackoverflow.com/questions/262264/
    http://stackoverflow.com/questions/237023/
    http://stackoverflow.com/questions/55901/
    http://stackoverflow.com/questions/41504/


    Jim Monty
  • Ted Byers at Aug 18, 2012 at 4:00 am
    On Fri, Aug 17, 2012 at 11:10 PM, Jim Monty wrote:

    Thanks again Jim,

    Ted wrote:
    Jim wrote:
    For a convenient list of all the time zones in the tz database, see
    http://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
    Given that it seems the entries are generaly 'continent/city', is there
    something in DateTime that will take any city or state and lookup the entry
    for the closest city? Or is that something I'll have to write, based on
    lat/lon data for cities (I am pretty sure I saw a database with lat/lon
    data for cities somewhere, but ... if it already exists, I don't have to
    write it)?
    There aren't any geocoding modules in the Perl DateTime suite (why would
    there be?), but there *are* plenty of geocoding Perl CPAN modules. Check
    out
    the Geo::Coder::* modules, for example.

    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.

    If you want to roll your own simple time zone aliases, check out
    DateTime::TimeZone::Alias:


    http://search.cpan.org/dist/DateTime-TimeZone-Alias/

    The simplest DIY solution is a lookup table using a hash.

    If you want to do something more elaborate, there are oodles of
    geocoding resources for programmers on the web:


    http://en.wikipedia.org/wiki/Geocoding
    http://askgeo.com/
    http://askgeo.com/database/TimeZone

    http://www.geonames.org/export/web-services.html#timezone
    http://stackoverflow.com/questions/262264/
    http://stackoverflow.com/questions/237023/
    http://stackoverflow.com/questions/55901/
    http://stackoverflow.com/questions/41504/


    Jim Monty
    I have begun to study the geonames database, but I hadn't happened up their
    web services.

    Thanks again

    Ted
  • Karen Etheridge at Aug 18, 2012 at 5:27 pm

    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.)
  • Ted Byers at Aug 18, 2012 at 7:11 pm

    On Sat, Aug 18, 2012 at 1:27 PM, Karen Etheridge 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
  • Jim Monty at Aug 19, 2012 at 4:26 am

    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.
    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

    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
    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.
    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.

    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.

    --------------------------------------------------------------------------

    C:\Demo>cat now.pl
    #!perl

    use strict;
    use warnings;

    use DateTime;
    use Geo::GeoNames;
    use URI::Escape;

    binmode STDOUT, ':encoding(UTF-8)';

    my $city = @ARGV ? shift : 'Tempe';

    my $geo = Geo::GeoNames->new( username => '*********' );

    my $result = $geo->search(
    q       => uri_escape_utf8($city),
    maxRows => 1,
    style   => 'FULL'
    );

    defined $result->[0] or die "Unrecognized city '$city'\n";

    my $city_name    = $result->[0]->{name};
    my $country_name = $result->[0]->{countryName};
    my $time_zone    = $result->[0]->{timezone}{content};
    my $time_now     = DateTime->now( time_zone => $time_zone );

    print "$city_name ($country_name) $time_now ($time_zone)\n";

    exit 0;

    C:\Demo>now
    Tempe (United States) 2012-08-18T20:47:15 (America/Phoenix)

    C:\Demo>now Flagstaff
    Flagstaff (United States) 2012-08-18T20:47:20 (America/Phoenix)

    C:\Demo>now "Window Rock"
    Window Rock (United States) 2012-08-18T21:47:26 (America/Shiprock)

    C:\Demo>now "Salt Lake City"
    Salt Lake City (United States) 2012-08-18T21:47:34 (America/Denver)

    C:\Demo>now "New York"
    New York (United States) 2012-08-18T23:47:42 (America/New_York)

    C:\Demo>now "Washington D.C."
    Washington (United States) 2012-08-18T23:47:52 (America/New_York)

    C:\Demo>now Saratoga
    Saratoga Springs (United States) 2012-08-18T23:48:15 (America/New_York)

    C:\Demo>now Baden-Württemberg
    Baden-Baden (Germany) 2012-08-19T05:49:11 (Europe/Berlin)

    C:\Demo>now Yūbari | cat -Uc8pa
    Yūbari-shi (Japan) 2012-08-19T12:50:41 (Asia/Tokyo)

    C:\Demo>now Bombay
    Mumbai (India) 2012-08-19T09:21:11 (Asia/Kolkata)

    C:\Demo>now Calcutta
    Kolkata (India) 2012-08-19T09:21:19 (Asia/Kolkata)

    C:\Demo>now "New Delhi"
    New Delhi (India) 2012-08-19T09:21:29 (Asia/Kolkata)

    C:\Demo>now Timbuktu
    Timbuktu (Mali) 2012-08-19T03:51:49 (Africa/Bamako)

    C:\Demo>now "Lake Chaubunagungamaug"
    Lake Chaubunagungamaug (United States) 2012-08-18T23:52:34 (America/New_York)

    C:\Demo>now Chargoggagoggmanchauggagoggchaubunagungamaugg
    Unrecognized city 'Chargoggagoggmanchauggagoggchaubunagungamaugg'

    C:\Demo>

    --------------------------------------------------------------------------

    Arizona is in the U.S. Mountain Time Zone, but Arizona doesn't observe
    daylight saving time. So Tempe and Flagstaff are in the 'America/Phoenix'
    time zone, not the 'America/Denver' time zone.

    Window Rock is in Arizona, but it's also in the Navajo Nation. Unlike the
    rest of Arizona, the Navajo Nation observes daylight saving time. So
    Window Rock is in the 'America/Shiprock' time zone. As it happens,
    Shiprock, a representative location in the Navajo Nation, is in New Mexico,
    not in Arizona.

    Salt Lake City is a big, well-known city that, like Phoenix, is in the
    U.S. Mountain Time Zone. But Utah observes daylight saving time, so Salt
    Lake City is in the 'America/Denver' time zone.

    When you look up Bombay in the GeoNames geographical database, you get
    Mumbai. When you look up Calcutta, you get Kolkata. When you look up
    New Delhi, you get New Delhi. All of these cities in India are in the
    'Asia/Kolkata' time zone.

    Jim Monty
  • Ted Byers at Aug 19, 2012 at 5:58 am

    On Sun, Aug 19, 2012 at 12:26 AM, Jim Monty 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedAug 17, '12 at 3:57p
activeAug 19, '12 at 5:58a
posts9
users3
websitemetacpan.org...

People

Translate

site design / logo © 2022 Grokbase