Given that this is TZDB-specific, we can expose it on TzdbDateTimeZoneSource, 
as that's visible post issue 144.

(When we've looked at all the metaZone stuff, we could expose that in the same 
way...)

This is the relevant sections of the CLDR specification:
http://www.unicode.org/reports/tr35/#Timezone_Names
http://www.unicode.org/reports/tr35/#Time_Zone_Fallback
http://www.unicode.org/reports/tr35/#Supplemental_Timezone_Data

Also relevant:
http://www.rfc-editor.org/rfc/bcp/bcp47.txt


Trying to read through this makes me want to run away and cry. I suspect it 
will get better over time though.

Relevant files I've found, relative to the root of the core.zip CLDR data 
archive, in the "common" directory ('cos everything is...):

- bcp47/timezone.xml (May not be useful? Not sure yet.)
- main/*.xml (timezoneNames element for each language)
- supplemental/metaZones.xml
- supplemental/windowsZones.xml

I'm starting to wonder whether it wouldn't make sense to include all the 
information in the windows zone mapping file in version 1.1, while we're 
already making a clean break to a new file format. We don't need to expose it 
all right now, but we could build the current mapping in memory from the fuller 
information.

That way we won't need to either duplicate a field or worry about backward 
compatibility when we get to version 1.3.

I'll investigate how much space it would add (which is all wasted until we 
expose the information of course) and we can make a decision based on that.

Looks like it only adds about 5K to the data, so I think it's worth doing 
sooner rather than later. We could actually expose it pretty easily, too (on 
TzdbDateTimeZoneSource) - it's just a matter of how "nicely" we want to do so.

More work than I'd expected to do it properly... but the change is now in a 
"CLDR Windows zones" branch.

A bit more testing required to include in 1.1, and a design review before we 
expose the information publicly (which might also be in 1.1).

Malcolm: this changes the stream format again, of course... so we should decide 
on it
soon, in order to potentially change the docs :)

This is implemented, and will be reviewed as part of issue 173.