-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
Description
APIs depending on GetTimeZoneIds, such as GetSystemTimeZones -> PopulateAllSystemTimeZones -> GetTimeZoneIds, will have an incorrect empty set of TimeZoneInfos.
Reproduction Steps
foreach (var tz in TimeZoneInfo.GetSystemTimeZones())
{
Console.WriteLine($"TimeZone: {tz.DisplayName}");
}
on an Android device/emulator running on API 21 leads to no time zones.
Expected behavior
Non-empty set of time zones being written to the console.
Actual behavior
No time zones being written to the console.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
Two pull requests are culpable for this behavior. #54845 and #64028
After porting over Mono's implementation to load time zone data in #54845, following the change to remove zone.tab on Android #41867 (comment), there was an issue where deprecated time zones were still inside the tzdata file alongside the updated/renamed time zone.
The solution at the time to determine what timezones were deprecated, A.K.A. "backwards", was to leverage the tzlookup.xml, and though it was noted that it didn't exist on API 19 or 24, the fallback was missed in the implementation to remove backward timezones.
What happens is that the public GetTimeZoneIds grabs all time zones, and filters out "duplicates" based on the _isBackwards "property". That property is set to TRUE if it is not found in tzlookup.xml, which if there isn't that file in the first place, would lead to all timezones being marked as backwards, and thus none are returned in GetTimeZoneIds.
Options:
- The easy fix to return a non-empty set would be to add a check if
tzlookup.xmlexists or if thetzLookupIDsis an empty set or not. - The more proper fix would be to figure out what ids are backwards without the
tzlookup.xml, which might be retaining a copy oftzlookup.xmlin runtime as suggested in [Android][TimeZone] Backward TimeZone IDs found in Android tzdata #63693 (comment)