Powershell: Get-Date Incorrectly formats MMM as "Sept" instead of "Sep"

[cawoodm]

Steps to reproduce

$> Get-Date -f MMM  # "Sep" is correct
Sep
$>Get-Date -f "dd MMM" # "25 Sept." is incorrect
25 Sept.

Expected behavior

Get-Date -f "dd MMM" should produce 25 Sep not 25 Sept.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[cawoodm]

Works fine in PowerShell 5.1 and PSCore 6.2.3

[doctordns]

I can not validate, I see this in 7.0.2 and 7.1.0-preview.7:#

PS C:\Foo> Get-Date -f "dd MMM" # "25 Sept." is incorrect
25 Sep

What culture are you using?

[vexx32]

This will be dependent on culture settings, which come from .NET.

If the culture you're using defines the month name in this way, PowerShell has to respect it. If this is actually a bug, it needs to be filed in the dotnet/runtime repository.

[mklement0]

The behavior is owed to a change in .NET Core between 3.x (up to PS v7.0) and the 5.0 preview we're currently using in the 7.1 previews, namely to the de (German) culture on Windows (note that on Unix it exhibited the behavior even in .NET Core 3.x).

(However, note that this contradicts the PS version number in the OP: I only see your symptom with PowerShell Core 7.1.0-preview.7, not with 7.0.3)

In other words: PowerShell is indeed not to blame, as @vexx32 points out.

As for whether it's worth creating an issue in the https://github.com/dotnet/runtime repository:

I don't think it's a bug, but the underlying design logic seems questionable - but a change would affect many cultures:

The change in behavior on Windows comes from the values returned by
([cultureinfo] 'de').DateTimeFormat.AbbreviatedMonthGenitiveNames having changed in 5.0, from, e.g., Sep to Sept.

Format specifier MMM refers to these values seemingly _if and only if_ a d or dd format specifier is _also_ present in the same string; otherwise, the ([cultureinfo] 'de').DateTimeFormat.AbbreviatedMonthNames values are used (note the absence of _Genitive_), and their values haven't changed in 5.0 (September is still Sep).

The same applies to MMMM andMonthNames / MonthGenitiveNames (unabbreviated).

Note that the docs for the format specifiers do not mention this behavior at all, and that the *Genitive*-related topics don't mention that the co-presence of d and dd (but not ddd or dddd) in the string triggers the behavior.

GitHub

dotnet/runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps. - dotnet/runtime

[iSazonov]

It is better to ask in .Net Runtime repository.

[msftbot[bot]]

This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.