Reverse get_global('windows_zone_mapping') to avoid data loss. Fixes #464

[ecederstrand]

trafficstars

Reverses get_global('windows_zone_mapping') keys and values and does not filter on territory. This preserves all input data and makes it possible to look up Windows timezone name for any supported timezone, while still supporting the previous functionality with a simple previous_output = {v:k for k, v in get_global('windows_zone_mapping')}.

It also makes 'windows_zone_mapping behave like the other timezone mappings which are indexed by timezone name.

This is backwards incompatible, but I'm not sure how much it matters since get_global('windows_zone_mapping') is technically an undocumented feature (see #463 )

[codecov-io]

Current coverage is 90.14% (diff: 100%)

Merging #465 into master will not change coverage

@@             master       #465   diff @@
==========================================
  Files            24         24          
  Lines          3979       3979          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits           3587       3587          
  Misses          392        392          
  Partials          0          0          

Powered by Codecov. Last update ab56a43...a7c0961

[akx]

Hey and sorry it's taken us ages to get back to this PR. 😞

Anyway I'm thinking we could do better here – what if we import the lossless, detailed mapping as, say, detailed_windows_zone_mapping or similar? The shape could be {(zone, territory): windows_zone, ...}.

Then it's trivial to create windows_zone_mapping during CLDR import time from that data. That'd leave us backward compatible API-wise (even if I don't exactly truly believe too many people are currently using windows_zone_mapping – it's hard to tell since Github's code search just turns up thousands of vendored copies of Babel) so this could be shipped in Babel 2.x.

[ecederstrand]

This solution is fine with me.

My use case is a Microsoft Exchange client that needs to translate from pytz timezones to Windows timezone names, and I ended up storing a static map with the translations, generated from the CLDR: https://github.com/ecederstrand/exchangelib/blob/master/exchangelib/winzone.py So this is no longer urgent for me, but I promise to use Babel instead when this is solved and hits a release :-)