On looking at the existing CLDR data (now that we have it in our QLocaleXML data files, where I can study it easily), I find that the overwhelming majority of time-zone abbreviations are in fact unique, despite the obvious scope for collisions (190 zones, up to 3 names for each (generic, standard, daylight-saving), 696 locales; only 450 abbreviations, 306 of which end in T; 34 are of length 5, 169 of length 4, 215 of length 3, 32 of length 2), in fact a significant proportion of the abbreviations only ever refer to one "metazone" (in CLDR terms; a group of zones that all share common rules, at least for some of their histories, loosely-speaking).

Furthermore, even where there are collisions, they may be locale-specific, in the sense that many locales may have at most one metazone using the given abbreviation, so even the collisions can, in most cases, be disambiguated as long as we know the right locale.

So we could map abbreviations at least to metazones; and each metazone has a definitive zone that it defaults to (albeit some locales override this; but this data is also in CLDR), that it is reasonable to use as the meaning of the abbreviation.

I suspect this would be expensive to do from the existing tables, but we could reasonably pre-digest some helper tables in Python when preparing the CLDR data. However, this is only really a viable option for the case where feature timezone_locale is enabled; it's not clear how readily we can get this information out of ICU or the platform-specific backends, and even if we can it may turn out to be expensive. None the less, it may equally turn out that they have APIs to support it; so we should at least investigate the possibility.