Re: Olson - Microsoft mappings
Josh, My deepest apologies for misunderstanding the Alias modules both times I read it over. You are totally correct in that Alias is very similar to what I'm looking for and that like what Ben suggested of using submodules of Alias I can get what I'm after. UI for end user selection would probably be a great topic for an article to go on datetime.perl.org - however that's off topic from this discussion. And it's off topic for this list. :) I disagree. The question of How do I get my end users to choose their timezone using the DateTime modules is a very relevant discussion because it's part of a complete application. If I made a world clock app and the only way for you to choose the timezone was to look through a list of 364 alphabetized Olson names (perhaps broken into 9 categories) you'd throw it away and use something more friendly (at least I'd hope you would ;) ). For instance, So what's the time in Ireland? Do you use Europe/Dublin or Europe/Belfast? What's the difference? Do you expect the end user to know that Dublin and Belfast are in Ireland before they can see the time in Ireland? Or another example, where the heck is Europe/Chisinau in the world and is this something I need to see right now? All the America/Kentucky, America/Indiana amd America/Boise entries are completely superfluous in a current world and confuse people (perhaps it's just my people, but I still had to deal with them). I'm sure there are others in the database but the US is what I'm most familiar with at the moment. So you want to throw out functionality just because you don't have a use for it? Throw it out from my particular application yes. Throw it out of DT absolutely not. I'm not even trying to throw it out, I'm just trying to remove the end users ability to see it because it's confusing them and they don't need it. I gaurantee you there are not 364 timezone/DST rules in use in the world today. The 364 zones are only needed if you are using dates in the past, which I'm not. Future timezone changes are a different story altogether. So you want to throw out backwards compatibility too? What are you going to do when a time zone changes rules and happens to coincide with another? If the UTC offset and DST rules coincide (aka they are the same zone) and there is no significant advantage to having it (for instance they are in different countries), then I'm going to only present the one most easily recoginizable one to people from that locale. I'm not intending to remove anything from the recognized list of zone names so any prior stored references to the now removed zone name would still work, the UI will just stop presenting that as an option for end users to select. For instance, the UI will only present ~6 time zones for the continental United States not 16 and if some reference to any of the other 10 still existed and the application was asked to use it, it would still work. My purpose is to make the end user's experience of finding their timezone easier and to give programmers peace of mind in programitcally building a UI for selecting a zone. I'd love to use something like what Ben suggested which grouped the zone names into their respective countries since that would get updated with any module upgrades. Going forward I'd like to focus on actually making Ben's suggestion a reality. I'd like to add that timezones should also have a description which could be presented to the end user to help describe the time zone in more detail. -- Michael --
Re: Olson - Microsoft mappings
Joshua == Joshua Hoblitt [EMAIL PROTECTED] writes: Joshua You have incorrectly attributed that comment to me. No, he had two chevrons in front of the text. This correctly attributes it as something you quoted. Although, it'd be nice if everyone used Emacs supercite instead of chevrons. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Re: Olson - Microsoft mappings
Michael Fair [EMAIL PROTECTED] wrote:
For instance, So what's the time in Ireland?
Do you use Europe/Dublin or
Europe/Belfast? What's the
difference?
Do you expect the end user to know that
Dublin and Belfast are in
Ireland
before they can see the time in Ireland?
This is a bit of a beef I have (as of earlier
today) with the Olson project. I've managed
to auto-map about 174 of the olson zones to
geographic places but am scared I may have to
do the rest by hand. I wish the names were
more along the lines of:
Oceania/Australia/Melbourne-Victoria
Rather than
Australia/Melbourne
Once I've completed my research we should have:
$time_zone{$continent}{$country}{$region} and/or
$time_zone{$continent}{$country}{$city}
I figure we should allow access to the data
such that we can get a list that looks like:
Oceania
- Australia
- Melbourne (Victoria)
It would probably be good to create
DateTime::TimeZone::Select to hold this data,
and then DateTime::TimeZone::Select::HTML and
DateTime::TimeZone::Select::Tk and
DateTime::TimeZone::Select::Terminal for
holding widgets for people to just drop in place.
Re: Re: Olson - Microsoft mappings
On Wed, 24 Sep 2003 [EMAIL PROTECTED] wrote:
This is a bit of a beef I have (as of earlier
today) with the Olson project. I've managed
to auto-map about 174 of the olson zones to
geographic places but am scared I may have to
do the rest by hand. I wish the names were
more along the lines of:
Oceania/Australia/Melbourne-Victoria
Rather than
Australia/Melbourne
Once I've completed my research we should have:
$time_zone{$continent}{$country}{$region} and/or
$time_zone{$continent}{$country}{$city}
You do realize that mapping time zones to countries will take a _lot_ of
maintenance, right?
Countries are changing all the time. Think back to the end of the cold
war, when the USSR dissolved, along with Yugoslavio and Czechoslovakia,
and at the same time E W Germany became a single country.
And how do you handle things like Taiwan Hong Kong? Are they separate
countries? Hong Kong was once sort of a separate country, but is now
clearly part of China. Is Taiwan part of China? Depends who you ask ;)
My wife is Taiwanese and I sure as hell think they're separate countries,
but ask many mainlanders and you'll get a different answer.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Olson - Microsoft mappings
Dave Rolsky wrote: You do realize that mapping time zones to countries will take a _lot_ of maintenance, right? Countries are changing all the time. Think back to the end of the cold war, when the USSR dissolved, along with Yugoslavio and Czechoslovakia, and at the same time E W Germany became a single country. While this is true, it is also true that there are many countries that are *not* changing all of the time. Users in these countries might prefer a more intuitive UI for timezone selection rather than the pedantically correct bulk Olson listings. Put another way, if we can find a way to programatically categorize say 50% of the Olson DB, this still has value -- correct, it does not automatically digest the entire Olson DB, but if it captures 90% of the timezones in common usage then this effort still has value. Matt
Re: Re: Olson - Microsoft mappings
On Wed, Sep 24, 2003 at 10:54:04AM -0500, Dave Rolsky said: You do realize that mapping time zones to countries will take a _lot_ of maintenance, right? Just as a FWIW ... http://blogs.gotdotnet.com/raymondc/PermaLink.aspx/8b23d26b-7e11-425d-b612-13396ef3ec71
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.)
snip
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|\toptgroup label=$key\n|;
foreach my $subkey( sort keys %{$time_zones{$key}} ) {
if (ref $time_zones{$key}{$subkey}) {
print qq|\t\toptgroup label=$subkey\n|;
foreach my $subsubkey( sort keys %{$time_zones{$key}{$subkey}} ) {
print qq|\t\t\toption
value=$time_zones{$key}{$subkey}{$subsubkey}$subsubkey/option\n|;
}
print qq|\t\t/optgroup\n|;
} else {
print qq|\t\toption
value=$time_zones{$key}{$subkey}$subkey/option\n|;
}
}
print qq|\t/optgroup\n|;
} else {
print qq|\toption value=$time_zones{$key}$key/option\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
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.) ..
