Description
Description
Android's system tzdata file containing detailing timezone information contains TimeZones that are considered "backwards" (aka legacy timezones) by Iana's distribution. A number of these "backwards" timezones will result in TimeZoneInfo objects that have the same DisplayName yet different Ids as exemplified in #63693.
The fix at the time was to leverage a tzlookup.xml file that had been shipped alongside the tzdata file starting from https://android.googlesource.com/platform/system/timezone/+/35467e1256656196572e77251683e349d8f1055a and regard the time zone ids within that file as "non-backwards" ids.
However, it was noted that not all supported versions of Android (API >= 25) will contain that tzlookup.xml, so it's unclear how to prevent duplicate DisplayNames from occurring.
The ultimate question is, what is the expectation for the set of timezones that is returned as the system timezones? Should timezones that are considered "backwards" be omitted or should they be considered as supported.
Option 1: Remove "backward" Ids that result in the duplicate DisplayNames
Option 2: Make the duplicate DisplayNames more unique
Note: The Ids within the tzlookup.xml file on Android list some TimeZone Ids that are considered "backwards" by the Iana distribution, so currently on Android 26+, we are filtering out (because of #64028) part of the set of "backwards" Ids, rather than an all or nothing.
Note: On Android Studio, using java.util.TimeZone and org.threeten.bp.ZoneId will not filter out any Ids, and will still retain the duplicate DisplayNames.
Reproduction Steps
Android API 21-25
foreach (var tz in TimeZoneInfo.GetSystemTimeZones())
{
Console.WriteLine($"ID: {tz.Id} | Display Name: {tz.DisplayName}");
}Expected behavior
Not sure if backward timezones should be omitted or not.
Actual behavior
All timezones within tzdata are returned, with some having the same DisplayName
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response