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