You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to read the localized standard and daylight display names of time zones on Unix, we are using ICU. There doesn't appear to be a "C" api for the generic name. There is an ICU C++ api to get the 'generic' name. However, we can only use the "C" apis and not the C++ apis. See Remove OSX Homebrew ICU dependency.
I can think of 2 ways to fix this:
Use the C++ apis on platforms that allow it (not OSX)
Read the CLDR data directly.
Some background from @mj1856, if we decide to take the second approach:
part of the reason generic names are challenging is because there are three different patterns in the raw data. Examples of each:
Pattern 1 – Generic name differs from both standard and daylight names:
Generic Name: “Pacific Time”
Standard Name: “Pacific Standard Time”
Daylight Name: “Pacific Daylight Time”
Pattern 2 – Generic name matches the standard name:
Generic Name: “Central European Time”
Standard Name: “Central European Time”
Daylight Name: “Central European Summer Time”
Pattern 3 – No generic name exists, so revert to the location based form:
Generic Name: none, so use “UK Time”
Standard Name: “Greenwich Mean Time”
Daylight Name: “British Summer Time”
I’m not sure exactly why, but I can confirm in these docs:
Generic name, such as "Pacific Time". Currently, this is not supported by ICU.
Not sure why they chose not to implement, but might have something to do with the above.
Also worth mentioning, CLDR Generic Name is not quite a one-to-one match with our idea of a Display Name. Consider that many build time zone pickers by iterating over all time zones given by TimeZoneInfo.GetSystemTimeZones, then putting them in a dropdown with Id for the value and DisplayName for the text shown to the user. This works because Display Names are unique within the results. It doesn’t quite work with Generic Name, as multiple different time zones will use the same Generic Name. For example, both Europe/Paris and Europe/Berlin will have “Central European Time” as their generic name, because they’re both in the same CLDR metazone. To build a picker for IANA zones that doesn’t actually show the Id to the user requires also asking the user for a country. If we use Generic Name as a Display Name, we might want to concatenate a country name or code, such as “Central European Time (France)” / “Central European Time (Germany)”.
The text was updated successfully, but these errors were encountered:
In order to read the localized standard and daylight display names of time zones on Unix, we are using ICU. There doesn't appear to be a "C" api for the generic name. There is an ICU C++ api to get the 'generic' name. However, we can only use the "C" apis and not the C++ apis. See Remove OSX Homebrew ICU dependency.
I can think of 2 ways to fix this:
Some background from @mj1856, if we decide to take the second approach:
part of the reason generic names are challenging is because there are three different patterns in the raw data. Examples of each:
Pattern 1 – Generic name differs from both standard and daylight names:
Generic Name: “Pacific Time”
Standard Name: “Pacific Standard Time”
Daylight Name: “Pacific Daylight Time”
Pattern 2 – Generic name matches the standard name:
Generic Name: “Central European Time”
Standard Name: “Central European Time”
Daylight Name: “Central European Summer Time”
Pattern 3 – No generic name exists, so revert to the location based form:
Generic Name: none, so use “UK Time”
Standard Name: “Greenwich Mean Time”
Daylight Name: “British Summer Time”
I’m not sure exactly why, but I can confirm in these docs:
Not sure why they chose not to implement, but might have something to do with the above.
Also worth mentioning, CLDR Generic Name is not quite a one-to-one match with our idea of a Display Name. Consider that many build time zone pickers by iterating over all time zones given by TimeZoneInfo.GetSystemTimeZones, then putting them in a dropdown with Id for the value and DisplayName for the text shown to the user. This works because Display Names are unique within the results. It doesn’t quite work with Generic Name, as multiple different time zones will use the same Generic Name. For example, both Europe/Paris and Europe/Berlin will have “Central European Time” as their generic name, because they’re both in the same CLDR metazone. To build a picker for IANA zones that doesn’t actually show the Id to the user requires also asking the user for a country. If we use Generic Name as a Display Name, we might want to concatenate a country name or code, such as “Central European Time (France)” / “Central European Time (Germany)”.
The text was updated successfully, but these errors were encountered: