While names work fine, there are several problems with time zone abbreviations returned by this library.
93
90
45
88
74
63
And more that have come up without being logged.
In general, there are a few causes:
CLDR doesn't have abbreviations for every time zone. It has some of them, but they are scattered haphazardly throughout the data. The example in #90 shows how a time zone only has a single daylight abbreviation and no standard or generic abbreviation.
We could use TZDB abbreviations as a fallback, but we don't. The problem there is that only English abbreviations exists, and in many cases there's just a numeric offset with no abbreviation. Additionally, it's impossible to know which abbreviation or offset should be used generically if the standard and daylight values differ. Even then - we have to resort to only using the current set of values, not historical ones.
The search algorithm in this library probably could be improved
Ultimately I think the solution is either:
Find a more reliable source of time zone abbreviation data
Remove all abbreviations capabilities from this library.
While names work fine, there are several problems with time zone abbreviations returned by this library.
93
90
45
88
74
63
And more that have come up without being logged.
In general, there are a few causes:
Ultimately I think the solution is either: