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
{{ message }}
Repository navigation
Short date pattern from 'ky' culture produces invalid output in .NET Core 3.0 #13316
I'm trying to convert date to string and then parse it back. I'm using short date pattern for that and 'ky' culture. Unfortunately this gives me FormatException when doing DateTime.ParseExact.
From my brief investigation it looks like the pattern, which is 'd-MMM yy' for 'ky' culture, produces additional . (dot) in output in .NET Core 3.0.
Simple code that demonstrates the issue (works fine in .NET Core 2.2):
I looked at the issue, I am seeing this is happened because we have fixed the abbreviated genitive month formatting in 3.0 through the issue https://github.com/dotnet/corefx/issues/2804 and the PR dotnet/coreclr#21230. This fix still good but it looks we want to fix the parsing side too to allow parsing the abbreviated genitive month names too. I'll look more at the fix.
In last December we have made a fix for the issue https://github.com/dotnet/corefx/issues/2804 allowing formatting dates with Genitive month names. The fix is good but we missed adding a support to the date parser to handle the genitive month names.
On Windows 10, there are 133 cultures with genitive names out of total 848 cultures.
Customer Impact
If the customer app dealing with date and time formatting and parsing functionality will be potentially broken if format a date with genitive months and then try to parse it back to DateTime. The parsing is going to throw exception. Some of the cultures uses date/time formatting pattern with genitive month names specifiers as the default format. For example, culture Ky uses a default short date pattern d-MMM yy produce a genitive month names in the date formatting and parsing such strings is going to throw exception.
Regression?
Yes, although the fix we did is not the real regression but the regression caused because we missed to add the parsing part with the fix.
Risk
The risk is low as we are going to allow the date parser to try the genitive month names so the failing case will start succeed.
Activity
stephentoub commentedon Aug 26, 2019
cc: @krwq, @tarekgh
tarekgh commentedon Aug 26, 2019
@ppekrol what OS you are running on? and are you running both 2.2 and 3.0 on the exact same OS?
stephentoub commentedon Aug 26, 2019
@tarekgh, FYI, I repro'd this on Windows 10 Build 18362: running on 2.2 there's no error, and running on 3.0 there's an error.
tarekgh commentedon Aug 26, 2019
Thanks @stephentoub, I'll take a look.
tarekgh commentedon Aug 26, 2019
I looked at the issue, I am seeing this is happened because we have fixed the abbreviated genitive month formatting in 3.0 through the issue https://github.com/dotnet/corefx/issues/2804 and the PR dotnet/coreclr#21230. This fix still good but it looks we want to fix the parsing side too to allow parsing the abbreviated genitive month names too. I'll look more at the fix.
CC @lillo42
tarekgh commentedon Aug 27, 2019
Description
In last December we have made a fix for the issue https://github.com/dotnet/corefx/issues/2804 allowing formatting dates with Genitive month names. The fix is good but we missed adding a support to the date parser to handle the genitive month names.
On Windows 10, there are 133 cultures with genitive names out of total 848 cultures.
Customer Impact
If the customer app dealing with date and time formatting and parsing functionality will be potentially broken if format a date with genitive months and then try to parse it back to DateTime. The parsing is going to throw exception. Some of the cultures uses date/time formatting pattern with genitive month names specifiers as the default format. For example, culture
Kyuses a default short date patternd-MMM yyproduce a genitive month names in the date formatting and parsing such strings is going to throw exception.Regression?
Yes, although the fix we did is not the real regression but the regression caused because we missed to add the parsing part with the fix.
Risk
The risk is low as we are going to allow the date parser to try the genitive month names so the failing case will start succeed.
tarekgh commentedon Aug 27, 2019
The fix of this issue will be included in 3.0 release per the PR dotnet/coreclr#26384.
Thanks @ppekrol for reporting this issue in the right time :-)
Bump to mono/mono@18920a83 (#3753)
Bump to mono/mono@18920a83 (#3753)