New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reverse get_global('windows_zone_mapping') to avoid data loss. Fixes #464 #465
base: master
Are you sure you want to change the base?
Conversation
Most other maps are also keyed by timezone name, so do the same with win_mapping. Don't take territory into account when creating the map - the other territories are also valid.
windows_zone_mapping
lossless. Fixes #464
Current coverage is 90.14% (diff: 100%)@@ 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
|
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, Then it's trivial to create |
This solution is fine with me. My use case is a Microsoft Exchange client that needs to translate from |
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 simpleprevious_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 )