TryParseExact not working as expected

[Mats391]

Description

TryParseExact works not as expected in net8. The code works correctly in net4.7.2

Reproduction Steps

Sample code

var foo = "Dez.20";
var culture = new CultureInfo("de-DE");
DateTime bar;
var parsed = DateTime.TryParseExact(foo, "MMM.yy", culture, DateTimeStyles.None, out bar);
Console.WriteLine("Parsed:" + parsed);

Expected behavior

The string gets parsed to DateTime 2020-12-01

Actual behavior

The string does not get parsed

Regression?

The code works in net4.7.2 and net4.8. It does no longer work in net6/8/9

Known Workarounds

No response

Configuration

Tested in net6/8/9 on Windows 10 x64

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

[pra2892]

The issue is likely due to changes in how .NET handles culture-specific abbreviated month names across versions. The solution above provides two approaches:

1. The standard approach using TryParseExact (which may fail in newer .NET versions)
2. A custom approach that handles the parsing manually for this specific case

The custom approach will work reliably across all .NET versions because it explicitly maps the German month abbreviations to their numeric values.

For a production environment, you might want to expand the monthMap dictionary to include all possible variations of month abbreviations in German that your application might encounter.

Here is the solution:

using System;
using System.Globalization;

class Program
{
    static void Main()
    {
       var foo = "Dez.20";
       var culture = new CultureInfo("de-DE");
        
        //Solution 1: Use full month name pattern
        DateTime bar1;
        var parsed1 = DateTime.TryParseExact(foo, "MMM.yy", culture, DateTimeStyles.None, out bar1);
        Console.WriteLine($"Standard approach - Parsed: {parsed1}, Result: {bar1:yyyy-MM-dd}");
        
        // Solution 2: Create a custom format provider that handles both abbreviated forms
        DateTime bar2;
        var parsed2 = TryParseGermanDate(foo, out bar2);
        Console.WriteLine($"Custom approach - Parsed: {parsed2}, Result: {bar2:yyyy-MM-dd}");
    }
    
    static bool TryParseGermanDate(string input, out DateTime result)
    {
        result = DateTime.MinValue;
        var culture = new CultureInfo("de-DE");
        
        // Try standard parsing first
        if (DateTime.TryParseExact(input, "MMM.yy", culture, DateTimeStyles.None, out result))
        {
            return true;
        }
        
        // If that fails, try manual parsing for the specific case
        string[] parts = input.Split('.');
        if (parts.Length != 2)
            return false;
            
        string monthAbbr = parts[0];
        string yearStr = parts[1];
        
        // Map abbreviated month names that might cause issues
        var monthMap = new Dictionary<string, int>(StringComparer.OrdinalIgnoreCase)
        {
            {"Jan", 1}, {"Feb", 2}, {"Mär", 3}, {"Mar", 3}, {"Apr", 4}, 
            {"Mai", 5}, {"Jun", 6}, {"Jul", 7}, {"Aug", 8}, 
            {"Sep", 9}, {"Okt", 10}, {"Nov", 11}, {"Dez", 12}, {"Dec", 12}
        };
        
        if (monthMap.TryGetValue(monthAbbr, out int month) && int.TryParse("20" + yearStr, out int year))
        {
            result = new DateTime(year, month, 1);
            return true;
        }
        
        return false;
    }
}

[elgonzo]

It seems that when using a culture like "de-DE", the AbbreviatedMonthGenitiveNames is falsely being used for parsing instead of AbbreviatedMonthNames despite there no d or dd being in the format string.

I am not certain of it, but the fact that bool r = DateTime.TryParseExact("Dez..20", "MMM.yy", new CultureInfo("de-DE"), DateTimeStyles.None, out var dt) (note the two periods in succession in the input string) parses successfully seems to indicate such.

@pra2892

The issue is likely due to changes in how .NET handles culture-specific abbreviated month names across versions.

Unlikely. This appears to be a bug unrelated to possible culture/region differences between runtime or host OS versions.

A string-formatted DateTime should parse successfully using the same format string and culture that was used for string-formatting within the same running process. In the following example below the string s should be parsed successfully, but it isn't (tested with .NET 8 on Win11 x64 as well as dotnetfiddle).

string format = "MMM.yy";
CultureInfo culture = new CultureInfo("de-DE");

Console.WriteLine(string.Join(',', culture.DateTimeFormat.AbbreviatedMonthNames));

string s = new DateTime(2025, 12, 1).ToString(format, culture);
Console.WriteLine(s);

var parsed = DateTime.TryParseExact(s, format, culture, DateTimeStyles.None, out var dt);
Console.WriteLine("Parsed:" + parsed);

[tarekgh]

@pra2892 is correct. The issue is in .NET we have fixed the parsing of the Genitive month names. de-DE has the abbreviated genitive month name Dez.. So, parsing Dez.20 will result at month Dez. and year 20 which will not match "MMM.yy pattern.

You have the option to override the abbreviated genitive month names and that should make the parsing work. Doing something like the following:

culture.DateTimeFormat.AbbreviatedMonthGenitiveNames = ["Jan", "Feb", "März", "Apr", "Mai", "Juni", "Juli", "Aug", "Sept", "Okt", "Nov", "Dez", ""];

[elgonzo]

@tarekgh

This is in conflict with the official documentation at https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings#MMM_Specifier The documentation is very clear about this:

The "MMM" custom format specifier represents the abbreviated name of the month. The localized abbreviated name of the month is retrieved from the DateTimeFormatInfo.AbbreviatedMonthNames property of the current or specified culture. If there is a "d" or "dd" custom format specifier in the custom format string, it is retrieved from the DateTimeFormatInfo.AbbreviatedMonthGenitiveNames property instead.

There is no d or dd format specifier in the format string MMM.yy, hence closing this issue is in error.

[tarekgh]

@elgonzo fair enough.

[tarekgh]

The fix of this should be in the lines:

runtime/src/libraries/System.Private.CoreLib/src/System/Globalization/DateTimeParse.cs

Line 3361 in a1997d4

if ((dtfi.FormatFlags & DateTimeFormatFlags.UseGenitiveMonth) != 0)

runtime/src/libraries/System.Private.CoreLib/src/System/Globalization/DateTimeParse.cs

Line 3461 in a1997d4

if ((dtfi.FormatFlags & DateTimeFormatFlags.UseGenitiveMonth) != 0)