Windows 2025 NZ month format Sept

IMHO One of the worst decisions in history!

As per the previous post, but with a little more detail, I notice the USA and Australia have not made the decision to adopt this, and because AU has the same Date formats as NZ, there is a quick work around when this explodes on Monday 1st will be to do the below:

Using Windows UI:
1st open and change: Settings > Time & Language > Language & Region > Regional Format to English (Australia)

This will also broadcast a WM_SETTINGCHANGE message to windows, so only an application restart is likely to be needed.

If you DON'T have any applications built using a non-unicode aware date format, you can probably skip this step:

2nd.

1. run: "intl.cpl" (It's got more options than launching it from: "Administrative Language Settings").
2. Navigate to Administrative Tab (on the top), click on "Change system locale...".
3. Select English (Australia).
   1. Don't select the "Beta: Use Unicode UTF-8..." option.
   2. This will also prompt for a reboot....I ignored that and then later ran: shutdown /g /f /t 30 /d EP:2:4 /p /c "Urgent Shutdown to fix Sep -> Sept issue" Note: this restarts and launches everything it can again.
4. If you have multiple user accounts on the system, then consider also using the "Copy settings..." button and select if you want / need to copy this Format: English (Australia) to system or new accounts.

Using Windows Registry:

Obviously don't do this if you don't know what you're doing etc...use at your own risk, test the below on non production machines etc ;)

Option 1:
The relevant keys for a workaround that will resolve the issue for both the Unicode and Non Unicode settings / applications (For NZ Users).

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language]

"InstallLanguage"="0409"

"Default"="1409"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Locale]

@="00000409"

"(Default)"="00001409"

[HKEY_CURRENT_USER\Control Panel\International]

"Locale" = "00000C09"

"LocaleName" = "en-AU"

"iCountry" = "61"

[HKEY_CURRENT_USER\Control Panel\International\Geo]

"Name" = "NZ"

"Nation" = "183"

[HKEY_USERS.DEFAULT\Control Panel\International]

"Locale" = "00000C09"

"LocaleName" = "en-AU"

"iCountry" = "61"

[HKEY_USERS.DEFAULT\Control Panel\International\Geo]

"Name" = "NZ"

"Nation" = "183"

Option 2:
The relevant keys for a longer term patch / format override, Unicode aware applications only (For NZ Users).

Noting there are some additional options where you might not need to change the region as above (New Apps that do what they are supposed to) these allow you to override the mmm format for the current user, even if the system is using the "Sept" format.

[HKEY_CURRENT_USER\Control Panel\International]

"sAbbrevMonthName9"="Sep"

"sShortMonthName9" = "Sep"

"sAbbrevMonthNames" = "Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec"

These override options should not require a reboot if you broadcast a "WM_SETTINGCHANGE" message to the OS by just changing something in the regional settings and changing it back etc, just an application restart...perhaps a logout~login

...Have fun, if you found this...hopefully it will take some of the pain out of your day! :)

Keywords: Unicode Common Locale Data Repository (CLDR) Sept Sep mmm dd-mmm-yyyy

Hello I belive I have found how and why Windows changed it's format to Sept for en-NZ format according to CLDR, however it caused me more confusion because if it follows the same CLDR rule, the abbrevation of June and July should also be 4 letters. And the en-AU should follow the same Sept, June, July abbrevation. So it's still not align with CLDR.

My investigation steps:
Step 1: Google/AI told me that ICU.DLL (in C:\Windows\System32 or C:\Windows\SysWOW64) is the core system library provided by Microsoft Windows. Right click the version of the dll (in Windows Server 2025) it shows 72.1.0.4.
Step 2: Open the release page of ICU dll, it claimes that version 72.1.0.1 aligns with CLDR 42 https://github.com/microsoft/icu/releases/tag/v72.1.0.1
Step 3. Open Unicode.org CLDR release 42 webpage, find the chart for locale="en", in the header it suggests it applies to sublocales such as "en_NZ, en_AU, en_GB". And in table line 2032-2035 it defines these sublocales should use "June, July, Sept..." for month abbrevated format(screenshot below) https://www.unicode.org/cldr/charts/42/summary/en.html

Step 4: In Windows Server Run Powershell commands such as below to test the month format:
[DateTime]::ParseExact("24 Sep 2026", "dd MMM yyyy", [System.Globalization.CultureInfo]::GetCultureInfo("en-NZ"))

As what you discussed above, the behaviour of Windows (C#, PowerShell) does not affect en-GB, en-AU, and does not affect June/July, meaning icu.dll does not align with CLDR42 as it claimed in its release note.

I would appreciated it if someone could review and clarify this. Is there something wrong with my investigation? Or icu.dll is just make statements with illusion?

Dear Les,

A recent update in Windows Server 2025 and Windows 11 has permanently changed the abbreviated month format for September from "Sep" to "Sept" for the New Zealand region. This alteration, which is causing disruptions for some older software, is a deliberate change to align with international data standards and there is no straightforward way to revert it through standard system settings.

The root of this change lies in Microsoft's adoption of the latest data from the Unicode Common Locale Data Repository (CLDR), a comprehensive repository of locale data that aims to standardize how software handles regional formatting. The CLDR for English (New Zealand) now specifies "Sept" as the correct three-letter abbreviation for September.

This modification has led to compatibility issues for applications and databases, particularly in New Zealand, that were coded to expect the traditional "Sep" format. When parsing formatted dates, such as those in "dd-MMM-yyyy" format, the unexpected "t" can cause exceptions and data entry failures.

Reverting to "Sep": Limited and Unofficial Options

For users and developers seeking to revert to the "Sep" abbreviation, the options are limited and fall outside of standard, supported system configurations.

The most direct, though officially undocumented, method to override this setting is by modifying the Windows Registry. While Microsoft does not officially support this for changing individual month abbreviations, it is possible to alter the system's default locale settings.

Users can navigate to the following registry key:

HKEY_CURRENT_USER\Control Panel\International

Within this key, it is possible to create or modify specific string values to define the abbreviated month names. The relevant value for September is sAbbrevMonthName9. By setting the data for this value to "Sep", you can force the system to use the older abbreviation. The full list of abbreviated month name values are:

• sAbbrevMonthName1 (January)
• sAbbrevMonthName2 (February)
• sAbbrevMonthName3 (March)
• sAbbrevMonthName4 (April)
• sAbbrevMonthName5 (May)
• sAbbrevMonthName6 (June)
• sAbbrevMonthName7 (July)
• sAbbrevMonthName8 (August)
• sAbbrevMonthName9 (September)
• sAbbrevMonthName10 (October)
• sAbbrevMonthName11 (November)
• sAbbrevMonthName12 (December)

It is crucial to exercise extreme caution when editing the Windows Registry, as incorrect changes can lead to system instability. It is highly recommended to back up the registry before making any modifications.

The only other workaround, as acknowledged by affected users, is to change the system's regional setting to "English (Australia)". However, this is not an ideal solution as it may introduce other unwelcome formatting changes for dates, times, and currency.

For software developers, the most robust long-term solution is to adapt their code to be more flexible in parsing date formats, accommodating both "Sep" and "Sept" for September.

In conclusion, while the shift to "Sept" is a deliberate and permanent change by Microsoft to align with international standards, it is possible to override this on a local machine through registry modification. However, this method is not officially supported and should be undertaken with care.

Best Regards,

Unfortunately the registry fix that previously worked did not today for any logon.

We ended up having to change each user from New Zealand to Australia, rebooting, and then the offending application would function normally again.

I've found that running this PowerShell as User can help

verify current setting:

(Get-Culture).DateTimeFormat.AbbreviatedMonthNames[8]

Change to Sep if required:

Set-ItemProperty `

  'HKCU:\Control Panel\International' `

  -Name sAbbrevMonthName9 `

  -Value 'Sep'
then verify with this again:

(Get-Culture).DateTimeFormat.AbbreviatedMonthNames[8]