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

DateTime.ToShortDateString on Linux #26088

Closed
LouisBernath opened this issue May 7, 2018 · 7 comments
Closed

DateTime.ToShortDateString on Linux #26088

LouisBernath opened this issue May 7, 2018 · 7 comments
Labels
area-System.Globalization enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@LouisBernath
Copy link

I already saw the issue #18345, and i respect that .NET core uses the operating system cababilities and that they may differ from what we see on windows.

Problem:
The DateTime.ToShortDateString produces a different string on a Linux (cflinuxfs2 / Ubuntu 14.04) or a Windows 10.
E.g. for "de-CH"
On Windows "01.01.2016"
On Linux "01.01.16"

It seems to me that ToShortDateString uses the "SHORT" ICU format. It is really unfortunate, that the ICU "de_CH" (en_US as well) locale does define the year only as a two digit. If you have dates from the 19th century, this is really a bummer when formatted with only two digits.

Proposal:
Could you at provide a way to use a standard format specifier to use the medium ICU format? (I know, Windows only has short or long)
Or a way to control if the short or medium ICU format is used. (Maybe the short format is not the right choice for some locales and ToShortDateString.)

Because of this i ended up using a custom format string. So I esentially loose the globalization feature for this particular case.

From http://userguide.icu-project.org/formatparse/datetime

SHORT is numeric, such as 12/13/52 or 3:30pm
MEDIUM is longer, such as Jan. 12, 1952
LONG is longer, such as January 12, 1952 or 3:30:32pm
FULL is completely specified, such as Tuesday, April 12, 1952 AD or 3:30:42pm PST

@tarekgh
Copy link
Member

tarekgh commented May 7, 2018

@Burnaster I am still seeing a gap between short and Medium. for example, if you want 12/13/1952, this is not short nor medium.

Would it be better to suggest the change to the ICU library, to update the short formats for such locales? the only concern I have, if we expose a new API, we'll still have a gap and will need to expose more APIs to fill such gaps. so fixing the ICU would make more sense.

@tarekgh
Copy link
Member

tarekgh commented May 7, 2018

The other idea could be, when we read the short date format from ICU we always force the 4-digit year instead of a 2-digit year.

@Burnaster does this will be better for you?

@LouisBernath
Copy link
Author

@tarekgh 4 year digits would be a lot better from my perspective and solve my problem.

@LouisBernath
Copy link
Author

@tarekgh As far as i understood the ICU relies on the CLDR project. I created a ticket stating my concern about the short date pattern; even though i don't see much chance for success in the near future due to the nature of the project and the unicode consortium: https://unicode.org/cldr/trac/ticket/11090

@tarekgh
Copy link
Member

tarekgh commented May 7, 2018

@Burnaster thanks. I'll try to look if we can force a 4-digit year in the short date format.

@tarekgh
Copy link
Member

tarekgh commented Jun 8, 2018

This should be fixed by the linked PR.

@tarekgh tarekgh closed this as completed Jun 8, 2018
@effyteva
Copy link

Hi,
For anyone suffering from this issue, I've create a simple solution.
https://github.com/effyteva/Teva.Common.Cultures

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 3.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Globalization enhancement Product code improvement that does NOT require public API changes/additions
Projects
None yet
Development

No branches or pull requests

4 participants