Provide more information on BCL time zone mappings

[GoogleCodeExporter]

CLDR now providers a 1-to-many mapping from Windows names to TZDB IDs. We 
currently map the "default" territory of "001" but we could give more 
information... it probably should be part of work to bring in other information 
from CLDR.

(There's scope for a whole other project to make CLDR information more 
universally accessible and useful from a .NET environment, but hey...)

Original issue reported on code.google.com by jonathan.skeet on 12 Jul 2012 at 12:22

[GoogleCodeExporter]

Original comment by malcolm.rowe on 13 Jul 2012 at 8:33

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by malcolm.rowe on 30 Jul 2012 at 7:47

• Added labels: Milestone-1.1-consider
• Removed labels: V1-OutOfScope

[GoogleCodeExporter]

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...)

Original comment by jonathan.skeet on 11 Nov 2012 at 12:22

[GoogleCodeExporter]

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

Original comment by jonathan.skeet on 13 Nov 2012 at 9:21

[GoogleCodeExporter]

Original comment by malcolm.rowe on 25 Jan 2013 at 8:32

• Added labels: Milestone-1.3.0
• Removed labels: Milestone-1.1-consider

[GoogleCodeExporter]

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.

Original comment by jonathan.skeet on 23 Feb 2013 at 9:04

• Added labels: Milestone-1.1-consider
• Removed labels: Milestone-1.3.0

[GoogleCodeExporter]

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.

Original comment by jonathan.skeet on 23 Feb 2013 at 10:23

[GoogleCodeExporter]

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 :)

Original comment by jonathan.skeet on 23 Feb 2013 at 5:36

• Changed state: Started

[GoogleCodeExporter]

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

Original comment by jonathan.skeet on 21 Mar 2013 at 2:50

[GoogleCodeExporter]

Original comment by jonathan.skeet on 21 Mar 2013 at 2:50

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by malcolm.rowe on 6 Apr 2013 at 9:27

• Added labels: Milestone-1.1.0
• Removed labels: Milestone-1.1-consider