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

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.

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.

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?

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

This issue was closed by revision 1a8208d3a4ce.

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.