> Ok - you have to write a small amount of glue code for your application.
Since I'm not trying to present my users with the full list of 364 zone names I expect to need to do some filtering and maintenance. I started out with the idea that "You know, most applications probably don't need to present their end users with 364 distinct timezones". > This thread started out with you saying: > > "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 differences)? > Would anyone be opposed to/in favor of that?" > > Which sounds like you are proposing to have TimeZoneCatalog.pm modified. > Modification which would add functionality you are now admitting doesn't > belong there. I'm not trying to be difficult here but what exactly are > you asking for? No "difficult" taken and please understand I'm not trying to be difficult either. :) I never said it doesn't belong in TimeZoneCatalog. I simply said it could be done without it. I don't have a full understanding of what TimeZoneCatalog is for - is it only to Catalog actual zone names, or is it a more generic "this is the module to help build UIs". The only purpose I could ever think of for this module is in building a UI. Either converting a time into all currently known timezones, or presenting a list of zone names to the end user so they can choose. My purposes seemed a natural extension of the UI aspects of TimeZoneCatalog so that's why I suggested adding it there. If in some way this conversation results in more support for building UIs being added to TimeZoneCatalog (where to me it looked like the most appropriate place to go) then it would be a modification of TimeZoneCatalog. I am asking if others think a standard set of oft used mappings would be useful to the DateTime family of modules (because I think they would). My first thought was that some extensions to TimeZoneCatalog would be the best place for those mappings and I wonder if others agreed. In the process of discussing this thread, the idea expanded to include some sort of dynamic routine that would take a date range and limit the list to just the relevant names that were active during that timespan. > > I wasn't even going to bother this group with it but I realized that > > this particular mapping (MS -> Olson) and probably a few others (group > > by country and legacy names for instance) would be useful enough and > > widespread enough that someone else might have already done the work. > > As I stated in my earlier e-mail I believe this will be difficult to implement properly. Perhaps so, but I think difficulty is really just a matter of scope. Originally I posted the list of 63 names from MS, each of those names will have an Olson entry that matches it. The only glue needed would be a function to get the list of those names and the Olson equivalents as a hash or hash reference. Another "mapping" could group by country. That would be a hash of arrays (country => tzs) To do the more dynamic stuff like filtering for only the currently relevant names I agree is more difficult. Also doing more complicated structures would be more difficult too. But the difficulty can be overcome by limiting the scope. The key thing for me is that if this is a project worth doing then it's worth doing well. I believe that the UI aspects of the Olson DB are currently a major hurdle to its widespread adoption. I can't just throw 364 names in a list and expect the end user to know what they are looking for. 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. > > It's really more like a package of useful constants that programmers > > might find useful... > > > > Hmm, how about a: DT::Mapping namespace which does pretty much just that... > > DateTime::Mapping is totally ambiguous - mapping what? Rick's namespace suggestion is better. Ok sounds great to me!! :) I didn't see his namespace suggestion just a specific example of having _a_ method that returned a Hash structure specific to countries. That's great if you want to group by countries, is that the only useful way to group time zones? But hey, if his namespace suggestion is better let's use that instead! :) Where can I read about it? Or was his "namespace" suggestion just a more generalized form of his country breakdown? > > The mappings always end up returning an Olson name as their final value, > > but has a generic tree structure to navigate to it. > > This is essentially what DT::TZ::Alias does except with a hash instead of a complex data structure. But more importantly these names don't get returned when you call all_names. TZ::Alias, as I understand it, actually creates a new and usable tz name. This module wouldn't. It's purely for building a UI so that an end user can select the appropriate Olson name. Perhaps I'm splitting hairs here, but I don't see any reason the application shouldn't use the actual Olson names internally. It doesn't need a real Alias that it can use with DT, it just needs something to make end user presentation of the database more friendly. > > Some of the lists I've seen in this thread could be: > > DT::Mapping::Microsoft # Mappings of MS timezone names > > It's incorrect. So what, it's a compatibility mapping for using a list that some people are more familiar with. Some people will find it helpful. Especially if they are using DT on an MS platform and what to look like an MS product or get a timezone name from an MS library. > > DT::Mapping::Current # Mappings of just currently distinct timezones > > This is the Olson DB. No it's not. 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. 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. Perhaps instead of "Current", "CurrentYear" would be clearer to you. > > DT::Mapping::ByCountry # Mapping from Country names to their used tzs > > Do you mean grouping Olson timezones by country? Yes. > > DT::Mapping might have some generic functions to handle getting/manipulating > > a giant HoHoH which the submodules could populate and the programmer could > > interface. > > Two separate arrays: one mapping continents to countries and one mapping Olson > timezones to countries would be more flexible. What a great idea!!!! What about countries to Olson names too? I'm thinking about dynamicly building the UI here: 1) user chooses continent 2) application gets listing for country 3) user chooses country 4) application gets list of timezones (This is also where a friendly "description" for each timezone would be useful.) 5) user chooses timezone done. Where in the DateTime family of modules should we put this? Is this interaction the only useful categorization or should we make it more generic so that it's easy for programmers to create new catagorizations that can be uploaded to CPAN? -- Michael --
