Yes, CLDR has what you need. It doesn't. It doesn't have timezone names, nor the capacity to collapse historically accrued timezones (with near-zero interest to modern users) ... You're making an unwarranted and unsupported generalization. The fact that this information is not interesting to you doesn't mean it isn't interesting to others.
If you want to filter timezone data to compress out the parts you don't care about, go right ahead. It's a small matter of programming once you know what you need.
True, but for maintenance purposes I try not to go too far out on a limb for such basic components... I had assumed tz would solve the 'reasonable list of timezones in current use' issue. Since tz apparently considers it out of scope, then the only real solution for our project's requirements appears to be ICU. This seems slightly obtuse, but is perfectly workable. Interestingly though, perhaps because unlike the tz database, ICU's focus is not that of providing a timezone database, at least some of the ICU bindings in other languages do not appear to provide any way to list available timezones (apparently provided by 'enumerate' functionality within ICU). *sigh* That one can be worked around, but in this day and age, so many hoops for such a fundamental dataset seems a little saddening. 2-bit notion of the email: perhaps the tz maintainers could recognize the problems with the current Olson IDs and consider a policy of importing aliases from the 'meta:' namespace within ICU without the associated multilingual names baggage? - Walter