Skip to content
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

TimeZoneInfo DisplayName is always set to StandardName on Unix #16232

Closed
eerhardt opened this issue Jan 27, 2016 · 2 comments
Closed

TimeZoneInfo DisplayName is always set to StandardName on Unix #16232

eerhardt opened this issue Jan 27, 2016 · 2 comments
Labels
area-System.DateTime bug os-linux Linux OS (any supported distro)
Milestone

Comments

@eerhardt
Copy link
Member

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:

  1. Use the C++ apis on platforms that allow it (not OSX)
  2. 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)”.

@mattjohnsonpint
Copy link
Contributor

👍

@tarekgh tarekgh removed their assignment Jan 3, 2017
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@joperezr joperezr removed the untriaged New issue has not been triaged by the area owner label Jul 1, 2020
mattjohnsonpint added a commit to mattjohnsonpint/dotnet-runtime that referenced this issue Mar 21, 2021
@tarekgh
Copy link
Member

tarekgh commented Mar 24, 2021

This should be fixed now by the PR #48931

@tarekgh tarekgh closed this as completed Mar 24, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Apr 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.DateTime bug os-linux Linux OS (any supported distro)
Projects
None yet
Development

No branches or pull requests

7 participants