I'd also be fine with TranslateWith or TranslateTo or similar naming.

I would *hope* the PrimaryMapping dictionary in WindowsMapping always maps to 
canonical IDs - I'm adding a validation check for that (which will be executed 
when creating a new nzd file). I'll see if it works.

For the reverse mapping, I think I'd prefer to create a method which returns a 
reverse mapping as a dictionary... but I'm not sure yet. Still considering it.

I don't see how the DateTimeZone method could work - imagine that someone else 
has come up with a new IDateTimeZoneProvider... there's no way that a 
BCL-originated zone can know how to translate that. I think this is a 
sufficiently rare scenario that requiring that the caller uses 
TzdbDateTimeZoneSource is reasonable.

The CLDR data intentionally doesn't follow links.  They require stable 
identifiers in the mapping data.  See 
http://unicode.org/cldr/trac/ticket/6971#comment:2

If we expect PrimaryMapping to contain TZDB canonical IDs, instead of just 
representing the CLDR map, then we'd have to resolve them at time of import.

I see your point about supporting a TranslateFor method generically for any 
IDateTimeZoneProvider would be difficult.  I was just thinking about the two 
existing providers.

How likely do you think it is that other time zone providers would be used?  
The only one I can even think of off the top of my head is the IATA zones used 
by the FAA, but they're not so fully functional anyway.

Please consider this or something like it for v2.0.  Thanks.

Also, we may want to consider that we currently build the CanonicalIdMap by 
following TZDB links, but the CLDR and TZDB disagree on what is "canonical".

In the case of ZoneA changing names to ZoneB, the TZDB says that ZoneB is now 
canonical and makes ZoneA a link.

However, CLDR requires stable identifiers, so it would consider ZoneA to 
_always_ be the canonical ID - adding ZoneB as an alias.

See: http://unicode.org/cldr/trac/ticket/6971

The CLDR canonical maps are in 
http://www.unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml

The first zone in the space-delimited list in the "alias" attribute is 
canonical by the CLDR.

Consider also that CLDR considers "Etc/GMT" to be canonical with "Etc/UTC" an 
alias, while TZDB considers each their own zone.  This requires an exception 
case in the mapping, as discussed here: 
http://stackoverflow.com/q/24394610/634824

I'm uncertain if there are any other exception cases like that one or not.

fwiw, http://stackoverflow.com/a/25092899/1774334 could have done with a 
reverse dictionary/method.