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