Re: Olson <-> Microsoft mappings
I agree with Joshua's intent. I think that the timezone selection right now is the most difficult part of using DateTime if the user has to specify it (and especially if you are not using a GUI). I agree that changing DT::TZ is probably not the right thing to do. Perhaps there should be a DT::TZ::Helper namespace? I would also love a module that would set up appropriate DT::TZ::Alias(es) for a given country. So if I loaded DT::TZ::Alias::Country qw(US); (or whatever) it would load EST as an alias for America/New_York. Finally, having the aliases US/Eastern makes a lot of sense to me. Perhaps it would make sense to make equivalent alises for all of the countries (possibly under a DT::TZ::Alias submodule). So for countries without different zones that is simply: China Britain Then for countries with multiple zones: Australia/Eastern etc. -ben On Mon, Sep 22, 2003 at 10:31:38PM -1000, Joshua Hoblitt wrote: > > It's become painfully obvious that having end users choose > > a timezone based on the huge list that is provided natively > > by DateTime::TimeZone::all_names just isn't very practical > > at this time. (Perhaps in the future when more people are > > used to dealing with the Olson names.) ..
TAN: Elmz - no mail
Is there some way I can turn off receieving email on this list without unsubscribing? I want to subscribe from two addresses (so messages are auto-approved) but only receive one copy. Cheers! Rick
Re: Olson <-> Microsoft mappings
> It's become painfully obvious that having end users choose
a timezone based on the huge list that is provided natively
by DateTime::TimeZone::all_names just isn't very practical
at this time. (Perhaps in the future when more people are
used to dealing with the Olson names.)
Is there anyway to do some work on TimeZoneCatalog to get some
different kinds of lists (for instance, a shortened list of
timezones that removes zones that only have historical differnces)?
Would anyone be opposed to/in favor of that?
At 10:31 PM -1000 22/9/03, Joshua Hoblitt replied:
I think you want DateTime::TimeZone::names_in_category(). Which
accepts a scalar from the array returned by categories() and itself
returns a list of Olson timezones.
Maybe there should be a method to get the list of zones as a
Hash-of-Hashes-of-Hashes such that we have:
$time_zones = {
'Oceania' => {
'Australia' => {
Melbourne => 'Australia/Melbourne',
Sydney=> 'Australia/Sydney',
},
'New Zealand' => {
Auckland => 'NewZealand/Auckland',
},
},
'North America' => {
'United States' => {
'New York' => 'America/NewYork',
},
}
}
This would mean that we have tree data that can be used in forms.
This code will turn it into a HTML select:
function make_select {
my %time_zones = (ref $_[0]) ? %{$_[0]} : @_;
foreach my $key ( sort keys %time_zones ) {
if (ref $time_zones{$key}) {
print qq|\t\n|;
foreach my $subkey( sort keys %{$time_zones{$key}} ) {
if (ref $time_zones{$key}{$subkey}) {
print qq|\t\t\n|;
foreach my $subsubkey( sort keys %{$time_zones{$key}{$subkey}} ) {
print qq|\t\t\t$subsubkey\n|;
}
print qq|\t\t\n|;
} else {
print qq|\t\t$subkey\n|;
}
}
print qq|\t\n|;
} else {
print qq|\t$key\n|;
}
}
The above code would allow you to feed it with a sub group of the
data hash or the whole hash:
$select = make_select( %time_zones );
$select_usa = make_select( $time_zones{'North America'}{'United States'} );
Re: Olson <-> Microsoft mappings
> It's become painfully obvious that having end users choose > a timezone based on the huge list that is provided natively > by DateTime::TimeZone::all_names just isn't very practical > at this time. (Perhaps in the future when more people are > used to dealing with the Olson names.) > Is there anyway to do some work on TimeZoneCatalog to get some > different kinds of lists (for instance, a shortened list of > timezones that removes zones that only have historical differnces)? > Would anyone be opposed to/in favor of that? I think you want DateTime::TimeZone::names_in_category(). Which accepts a scalar from the array returned by categories() and itself returns a list of Olson timezones. > Perhaps this would lead to a new way of working with timezones > where a named list of friendly names is put into the catalog > which serve as aliases to the real Olson Zone. That way, > programmers could present their users with a list that's > more tailored to their application rather than every zone name... > There could be some predefined lists that we expect many people > will want to use, or the programmer can define their own and > load the named list into the catalog on application startup. > That way later on, the programmer can just call up the catalog > by name and get both the friendly human presentable version that > has been localized to their application and the naked Olson Zone > name it represents. This sounds a lot like DateTime::TimeZone::Alias. > (For instance, if it's an application for US only, it could > restrict the list to just those zones and present the user > with more recognizable names than the Category/City name, > or like myself, I only care about zones that are different > from this year forward, and don't care about differences > that existed in the past because I won't deal with past dates > so I can restrict the list based on that) > I would hate to overload the categories call for this, but > it seems to serve a similar purpose Why would you need to override a class method to supply different and admittedly application specific functionality? Why not just keep your own list of timezones in a data structure with mappings to Olson timezones? Or you could just use DT::TZ::Alias. -J --
Olson <-> Microsoft mappings
Hi guys, I was wondering if anyone here had a mapping of the 63 timezones that Microsoft uses to their Olson equivalents. It's become painfully obvious that having end users choose a timezone based on the huge list that is provided natively by DateTime::TimeZone::all_names just isn't very practical at this time. (Perhaps in the future when more people are used to dealing with the Olson names.) I was originally going to try and create some graphical map that allowed one to click on the location they lived, but have since decided to present the same list of 63 time zones that Microsoft provides. Since my application only cares about forward moving time and has no need to convert based on historical differences, many time zones end up being the same for my purposes and this change will make the list the end users need to wade through a bit more intuitive. I've provided a copy of the 63 timezones below in case anyone else is interested. If anyone has already done this work I would appreciate a pointer. Otherwise I'll go through and do it myself and can post the results here. (Probably as html MS Name) Is there anyway to do some work on TimeZoneCatalog to get some different kinds of lists (for instance, a shortened list of timezones that removes zones that only have historical differnces)? Would anyone be opposed to/in favor of that? Perhaps this would lead to a new way of working with timezones where a named list of friendly names is put into the catalog which serve as aliases to the real Olson Zone. That way, programmers could present their users with a list that's more tailored to their application rather than every zone name... There could be some predefined lists that we expect many people will want to use, or the programmer can define their own and load the named list into the catalog on application startup. That way later on, the programmer can just call up the catalog by name and get both the friendly human presentable version that has been localized to their application and the naked Olson Zone name it represents. (For instance, if it's an application for US only, it could restrict the list to just those zones and present the user with more recognizable names than the Category/City name, or like myself, I only care about zones that are different from this year forward, and don't care about differences that existed in the past because I won't deal with past dates so I can restrict the list based on that) I would hate to overload the categories call for this, but it seems to serve a similar purpose Anyone else have any ideas or pointers? -- Michael -- The list of the 63 timezones Microsoft recognizes: GMT-12:00 Eniwetok, Kwajalein GMT-11:00 Midway Island, Samoa GMT-10:00 Hawaii GMT-09:00 Alaska GMT-08:00 Pacific Time (US & Canada), Tijuana GMT-07:00 Arizona GMT-07:00 Mountain Time (US & Canada) GMT-06:00 Central Time (US & Canada) GMT-06:00 Mexico City, Tegucigalpa GMT-06:00 Saskatchewan GMT-05:00 Bogota, Lima, Quito GMT-05:00 Eastern Time (US & Canada) GMT-05:00 Indiana (East) GMT-04:00 Atlantic Time (Canada) GMT-04:00 Caracas, La Paz GMT-04:00 Santiago GMT-03:00 Newfoundland GMT-03:00 Brasilia GMT-03:00 Buenos Aires, Georgetown GMT-02:00 Mid-Atlantic GMT-01:00 Azores, Cape Verde Is. GMT Casablanca, Monrovia GMT Greenwich Mean Time: Dublin, Edinburgh, Lisbon, London GMT+1:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna GMT+1:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague GMT+1:00 Brussels, Copenhagen, Madrid, Paris, Vilnius GMT+1:00 Sarajevo, Skopje, Warsaw, Zagreb GMT+2:00 Athens, Istanbul, Minsk GMT+2:00 Bucharest GMT+2:00 Cairo GMT+2:00 Harare, Pretoria GMT+2:00 Helsinki, Riga, Tallinn GMT+2:00 Jerusalem GMT+3:00 Baghdad, Kuwait, Riyadh GMT+3:00 Moscow, St. Petersburg, Volgograd GMT+3:00 Nairobi GMT+3:30 Tehran GMT+4:00 Adu Dhabi, Muscat GMT+4:00 Baku, Tbilisi GMT+4:00 Kabul GMT+5:00 Ekaterinburg GMT+5:00 Islamabad, Karachi, Tashkent GMT+5:30 Bombay, Calcutta, Madras, New Delhi GMT+6:00 Astana, Almaty, Dhaka GMT+6:00 Colombo GMT+7:00 Bangkok, Hanoi, Jakarta GMT+8:00 Beijing, Chongqing, Hong Kong, Urumqi GMT+8:00 Perth GMT+8:00 Singapore GMT+8:00 Taipei GMT+9:00 Osaka, Sapporo, Tokyo GMT+9:00 Seoul GMT+9:00 Yakutsk GMT+9:00 Adelaide GMT+9:30 Darwin GMT+10:00 Brisbane GMT+10:00 Canberra, Melbourne, Sydney GMT+10:00 Guam, Port Moresby GMT+10:00 Hobart GMT+10:00 Vladivostok GMT+11:00 Magadan, Solomon Is., New Caledonia GMT+12:00 Auckland, Wellington GMT+12:00 Fiji, Kamchatka, Marshall Is.
