Provide more information about time zone aliases

[GoogleCodeExporter]

Currently we do support time zone aliases, but all aliases are created equal - 
so there's no way of telling which of (say) Africa/Timbuktu or Africa/Bamako is 
the canonical form.

Options:
- Leave the canonical ID in the zone, so if you ask for an alias you get the 
exact same time zone object as the canonical one.
- Build separate objects, but have both the alias and the ID as properties
- Expose an alias map separately in the provider

Original issue reported on code.google.com by jonathan.skeet on 28 Jan 2012 at 9:01

[GoogleCodeExporter]

Original comment by jonathan.skeet on 17 Mar 2012 at 9:21

• Added labels: V1-OutOfScope

[GoogleCodeExporter]

Original comment by jonathan.skeet on 17 Mar 2012 at 9:21

• Added labels: V1-OutOfScope

[GoogleCodeExporter]

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

• Added labels: Type-Enhancement

[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]

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

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

[GoogleCodeExporter]

Is this still an issue?  I thought we were doing the first of those already 
("if you ask for an alias you get the exact same time zone object as the 
canonical one").

Original comment by malcolm.rowe on 10 Nov 2012 at 9:34

[GoogleCodeExporter]

Is this still an issue?  I thought we were doing the first of those already 
("if you ask for an alias you get the exact same time zone object as the 
canonical one").

Original comment by malcolm.rowe on 10 Nov 2012 at 9:34

[GoogleCodeExporter]

Yes, it's still an issue. I'd expected that behaviour, but we don't get it:

var provider = DateTimeZoneProviders.Tzdb;
Console.WriteLine(provider["Europe/Jersey"].Id); // Europe/Jersey

I'd have expected Europe/London. Hmm.

Original comment by jonathan.skeet on 10 Nov 2012 at 3:48

[GoogleCodeExporter]

Yes, it's still an issue. I'd expected that behaviour, but we don't get it:

var provider = DateTimeZoneProviders.Tzdb;
Console.WriteLine(provider["Europe/Jersey"].Id); // Europe/Jersey

I'd have expected Europe/London. Hmm.

Original comment by jonathan.skeet on 10 Nov 2012 at 3:48

[GoogleCodeExporter]

Right, the code is pretty simple. We have a dictionary in the resources, but 
when we ask for a time zone, we load it *from* the canonical name, but tell it 
that its ID was the one we asked for.

Given that this isn't something which applies to the BCL, I'm tempted to create 
an interface for "stuff which TZDB provides but isn't in all time zones" - 
which would expose a CanonicalId property to start with. We can very easily do 
this with no change in the resource format.

Original comment by jonathan.skeet on 10 Nov 2012 at 4:11

[GoogleCodeExporter]

Right, the code is pretty simple. We have a dictionary in the resources, but 
when we ask for a time zone, we load it *from* the canonical name, but tell it 
that its ID was the one we asked for.

Given that this isn't something which applies to the BCL, I'm tempted to create 
an interface for "stuff which TZDB provides but isn't in all time zones" - 
which would expose a CanonicalId property to start with. We can very easily do 
this with no change in the resource format.

Original comment by jonathan.skeet on 10 Nov 2012 at 4:11

[GoogleCodeExporter]

Suggestion for TzdbDateTimeZoneSource: we should expect it to have extra 
properties of:

- IDictionary<string, string> CanonicalIdMap (e.g. Europe/Jersey to 
Europe/London)

- Lookup<string, string> Aliases (e.g. Europe/London to { Europe/Jersey, 
Europe/Guernsey, Europe/Isle_of_Man })

- Lookup<string, string> SystemIdAliases (e.g. GMT Standard Time to { 
Europe/London, Atlantic/Canary, Atlantic/Faeroe, ... }) - see issue 82.

- IDictionary<string, string> SystemIdMap (e.g. Europe/London to GMT Standard 
Time)

Question: should an alias list include the canonical version, or just 
"different" aliases?

Original comment by jonathan.skeet on 11 Nov 2012 at 1:14

[GoogleCodeExporter]

Suggestion for TzdbDateTimeZoneSource: we should expect it to have extra 
properties of:

- IDictionary<string, string> CanonicalIdMap (e.g. Europe/Jersey to 
Europe/London)

- Lookup<string, string> Aliases (e.g. Europe/London to { Europe/Jersey, 
Europe/Guernsey, Europe/Isle_of_Man })

- Lookup<string, string> SystemIdAliases (e.g. GMT Standard Time to { 
Europe/London, Atlantic/Canary, Atlantic/Faeroe, ... }) - see issue 82.

- IDictionary<string, string> SystemIdMap (e.g. Europe/London to GMT Standard 
Time)

Question: should an alias list include the canonical version, or just 
"different" aliases?

Original comment by jonathan.skeet on 11 Nov 2012 at 1:14

[GoogleCodeExporter]

I've started implementing CanonicalIdMap and Aliases now; SystemIdAliases will 
require a format change, and therefore discussion on compatibility.

Original comment by jonathan.skeet on 11 Nov 2012 at 6:42

• Changed state: Started

[GoogleCodeExporter]

I've started implementing CanonicalIdMap and Aliases now; SystemIdAliases will 
require a format change, and therefore discussion on compatibility.

Original comment by jonathan.skeet on 11 Nov 2012 at 6:42

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision 1a8208d3a4ce.

Original comment by jonathan.skeet on 11 Nov 2012 at 9:09

• Changed state: Fixed

[GoogleCodeExporter]

This issue was closed by revision 1a8208d3a4ce.

Original comment by jonathan.skeet on 11 Nov 2012 at 9:09

• Changed state: Fixed

[GoogleCodeExporter]

Note that this *doesn't* fix issue 82; that's still pending, but as it's 
already got its own issue, I see no reason to leave this one open.

Original comment by jonathan.skeet on 11 Nov 2012 at 9:24

[GoogleCodeExporter]

Note that this *doesn't* fix issue 82; that's still pending, but as it's 
already got its own issue, I see no reason to leave this one open.

Original comment by jonathan.skeet on 11 Nov 2012 at 9:24

[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

[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