## 🐞 Bug Report: `DateTime.ParseExact` fails with `"dd. MMM. yyyy"` format in `"de-DE"` culture on .NET 7+ due to ICU misinterpretation of literal dot

[High-Nooner]

Description

DateTime.ParseExact fails to parse German date strings like "10. Okt. 2025" using format "dd. MMM. yyyy" and culture "de-DE" in .NET 7+, even though the format explicitly includes the dot after the month abbreviation as a literal.

Steps to Reproduce

var date = "10. Okt. 2025";
var formats = new[] { "dd. MMM. yyyy" };
var culture = CultureInfo.CreateSpecificCulture("de-DE");
DateTime.ParseExact(date, formats, culture, DateTimeStyles.None);

Expected Behavior

Should parse successfully. The format string includes a literal dot after MMM, so "Okt." should be interpreted as "Okt" (month) + "." (literal) as it is parsed with any other special character.

Actual Behavior

Throws FormatException: string '10. Okt. 2025' was not recognized as a valid DateTime.

Regression

Works with .Net 4.81

Root Cause Hypothesis

Other than .Net 4.81, .NET 7+ uses ICU globalization, which returns "Okt" (without dot) in AbbreviatedMonthNames. ParseExact matches "MMM" against this list and fails to parse "Okt.", treating the dot as part of the month name rather than a literal.

Evidence of Inconsistency

Other literal characters (e.g., +, -, *) placed after MMM in the format string work correctly with PowerShell 7.5.3 (.Net 7+) and 5.1: (.Net 4.8.1)

$Date = '10. Okt+ 2025'
$DateFormat = @('dd. MMM+ yyyy')
$Culture = [System.Globalization.CultureInfo]::CreateSpecificCulture('de-DE')
[datetime]::ParseExact($Date, $DateFormat, $Culture, [System.Globalization.DateTimeStyles]::None)
# Output: Freitag, 10. Oktober 2025 00:00:00

This proves that ParseExact respects literal characters — except for the dot (.), which is mishandled.

Known Workarounds

No workaround. User must change his Input by removing the dot ot the developer must changed the code by using 'TryParseExact'

Configuration

Powershell 5.1.26100.6725 on Net 4.8.1 and Powershell 7.5.3 with Net 7+ (9.0 is installed)
Windows 11 26200.6725
Architecture: x64
Behavior is not configuration but .Net specific.

Other information

Why This Is a Bug

• The dot is part of the format string, not the month name.
• ParseExact should tokenize "MMM." as a format token followed by a literal dot.
• This breaks compatibility with .NET Framework and violates the documented behavior of ParseExact.

---

Suggested Fix

Ensure ParseExact respects literal characters in the format string and does not rely solely on AbbreviatedMonthNames for MMM. The parser should treat "MMM." as a format token followed by a literal dot.

[dotnet-policy-service]

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

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• TryParseExact not working as expected #114159

[am11]

Tested with .NET 9 and 10 (yesterday's 13.10.2025 build).

1. With two dots after month in the input, ParseExact doesn't throw:

var date = "10. Okt.. 2025";
var formats = new[] { "dd. MMM. yyyy" };

2. Without a dot after month in the format and the input, it doesn't throw as well:

var date = "10. Okt 2025";
var formats = new[] { "dd. MMM yyyy" };

3. Without a dot after month in the format and a dot in the input month, it still works:

var date = "10. Okt. 2025";
var formats = new[] { "dd. MMM yyyy" };

@tarekgh, is it expected that both 2 or 3 are valid simultaneously?

[colejohnson66]

As noted in #114159, this is fixed by #114194, and it will be in .NET 10.

[am11]

@colejohnson66, see my comment. I tested with net10 as well.

[High-Nooner]

@tarekgh
when parsing input or generating output of dates, the only responsibility for the layout of the date-text has the designer. The basic rules the designer has to take care is the the meaning of the format code definitions (dd, MMM, etc.) and the separators which can be any special character or a blank and regional standards. To address implementation of such designs, the 'DateFormat' parameter has been implemented as an array. This also implies, that the date-components can contain only numbers and letters.

Therefore month names - full or abbreviations - may not contain any special character. The Programmers docs do not reference this precisely enough.

[tarekgh]

This behavior is working as expected.

The key detail you’re missing is that when parsing with a format that includes dd and MMM, the parser prefers using abbreviated genitive month names.

If you inspect the list of abbreviated genitive month names for the de-DE culture:

Console.WriteLine($"AbbreviatedMonthGenitiveNames: [{string.Join(",", culture.DateTimeFormat.AbbreviatedMonthGenitiveNames.Select(m => "'" + m + "'"))}]");

// Output:
// AbbreviatedMonthGenitiveNames: ['Jan.','Feb.','März','Apr.','Mai','Juni','Juli','Aug.','Sept.','Okt.','Nov.','Dez.','']

Notice that the abbreviated genitive month name for October is Okt. (with a trailing dot).
This means the date string 10. Okt. 2025 is parsed as:

• 10 → day
• . → separator
• Okt. → abbreviated genitive month name
• 2025 → year

There is no separator after the month name.
Therefore, the format dd. MMM. yyyy won’t match because it expects a . after the month name, which doesn’t exist in the input string.

You can see this clearly if you format the date using the same pattern:

Console.WriteLine($"{new DateTime(2025, 10, 10).ToString("dd. MMM. yyyy", CultureInfo.GetCultureInfo("de-DE"))}");

// Output:
// 10. Okt.. 2025

Notice the two dots; one from the month name Okt. and one from the format separator.

---

Examples

✅ Parses successfully:

var date = "10. Okt.. 2025";
var formats = new[] { "dd. MMM. yyyy" };

• 10 matches dd
• . matches .
• Okt. matches MMM
• . matches .
• 2025 matches yyyy

✅ Also parses successfully:

var date = "10. Okt. 2025";
var formats = new[] { "dd. MMM yyyy" };

✅ And this works too:

var date = "10. Okt 2025";
var formats = new[] { "dd. MMM yyyy" };

In this last case, the parser can’t match the abbreviated genitive month name Okt. (since there’s no dot), so it falls back to the regular abbreviated month name, which succeeds.

Console.WriteLine($"AbbreviatedMonthNames: [{string.Join(",", culture.DateTimeFormat.AbbreviatedMonthNames.Select(m => "'" + m + "'"))}]");

// Output:
// AbbreviatedMonthNames: ['Jan','Feb','Mär','Apr','Mai','Jun','Jul','Aug','Sep','Okt','Nov','Dez','']
// (Note: No dot after 'Okt')

---

Finally, if you’re running on .NET Framework, the behavior differs because it uses legacy Windows globalization data (NLS), not Unicode CLDR data from ICU.
In the legacy data, the abbreviated genitive month name for October is Okt (without the dot), which explains the different results.

I’m closing this issue since the behavior is by design, but please feel free to reply with any questions, I’ll be happy to help further.