c# - Why might my local machine be incorrectly formatting international dates?

Question

Here's a weird one...

I've just seen a (previously passing) test fail because of extra spaces in a string representation of a date. The test in question has previously passed in CI and on my local machine, but is now failing (on my local machine) because of extra spaces between segments of the date.

The same behaviour is exhibited by the following MCVE:

using System;
using System.Globalization;

public class Program
{
    public static void Main()
    {
        var date = new DateTime(2018, 01, 31);
        var format = "d/M/yyyy";
        var skSK = new CultureInfo("sk-SK");
        Console.WriteLine(date.ToString(format, skSK));
    }
}

In most places (including .NET Fiddle) this correctly returns:

31.1.2018

But on my machine, I now get:

31. 1. 2018

Note the extra spaces!

I'm confident that this was working as expected on my local PC just earlier this week, as I was using the project with this test in as a starting point for some experimentation with coverage tools. When I've resumed that experimentation this afternoon, the coverage file is no longer being produced due to the newly failing test.

What could have changed on my PC to cause this broken behaviour?

Answer 1

In Windows (like many others System), the source for the Locale date/time formats is the Unicode Common Locale Data Repository (CLDR), which provides internationalization and localization support specific for software developers and linguists.

A Short list of meaningful users:

• Microsoft (Windows, Office, Visual Studio etc.)
• Apple (macOS, iOS, watchOS, tvOS, Apple Mobile Device Support and iTunes for Windows;
• Google (Web Search, Chrome, Android, Adwords, Google+, Google Maps, Blogger, Google Analytics)
• IBM (DB2, Lotus, Websphere, Tivoli, Rational, AIX, i/OS, z/OS)
• Amazon

See the Online data explorer of the Localizations: Locale Explorer.

The Short Date format, localized to the sk-SK culture as d. M. yyyy, is the one listed in this archive. It's the same for all OS (Windows 7 to Window 10).

A MS Developer related blog: Locale Builder and Finnish or other locales.

Fiddler or other Online code-runners services are not a source of comparison on this matter.
Locales are different from system to system. Also, these international formats change over time and depend on the updates that a system receives (if it receives these updates at all).

In Windows 7 and Windows 10, the default Short Date format for the sk-SK Culture is d. M. yyyy.
But the DateTime patterns do not match, if the formats list is parsed further.

string format = CultureInfo.CreateSpecificCulture("sk-SK")
                           .DateTimeFormat.GetAllDateTimePatterns()[1]; 

In Windows 7, the second element in the DateTimePatterns list is d.M.yyyy
In Windows 10, the element at the same index is: dddd d. MMMM yyyy

A Windows update may change the default pattern for any of the Locales (without explicit notification).
It's understood that applications must provide parsing means for special cases. Or refer to the user Locale settings when formatting, without trying to force a specific pattern for internal uses.
Date/Time formats should be used for presentation only. The Locale and the user settings determine that format. An user of a System may decide to use a different format than the default Locale.

This GitHub repository holds an updated JSON of the CLDR database:
CLDR Date Modern

Also interesting, the ECMAScript reference for API internationalization:
ECMAScript? 2017 Internationalization API Specification

MSDN latest guidelines for Globalization and localization (UWP related):
Globalization and localization
Globalize your date/time/number formats
Use the Multilingual App Toolkit 4.0