Why is string.Format("{0:d}", DateTime.Now) returning "yyyy-MM-dd" instead of US-local "M/d/yyyy" after changing local display settings?

Question

When looking into some failing tests, I discovered this unexpected outcome:

// Expected "3/6/2017"
string.Format("{0:d}", System.DateTime.Now)
"2017-03-06"

// Expected "3/6/2017 09:31:13 AM" (or similar)
string.Format("{0}", System.DateTime.Now)
"2017-03-06 09:31:13"

string.Format("{0:G}", System.DateTime.Now)
"2017-03-06 09:31:13"

[The results are consistent from the nunit console runner, Visual Studio's interactive console, and LINQPad. Since the results are the same in LINQPad, without the rest of the code running it, seems like a machine/global configuration issue - fitting, since I changed the local machine's date/time display format.]

Wait.. what? This is clearly different than my expectations of the US-localized "3/6/2017 09:31:13".

• Why is this occurring, and where is this behavior clearly documented?

  Is the culture not 'true' en-US anymore?

• How can I ensure that the output follows en-US rules?

  How can the output be guaranteed to follow the machine's localization settings regardless of machine specific setting modifications?

Since it is a formatting-localization issue, I also captured the current culture. It appears that a culture of "en-US" is not sufficient to guarantee consistent formatting.

---

System.Threading.Thread.CurrentThread.CurrentCulture
{en-US}
    Calendar: {System.Globalization.GregorianCalendar}
    CompareInfo: {CompareInfo - en-US}
    CultureTypes: SpecificCultures | InstalledWin32Cultures | FrameworkCultures
    DateTimeFormat: {System.Globalization.DateTimeFormatInfo}
    DisplayName: "English (United States)"
    EnglishName: "English (United States)"
    IetfLanguageTag: "en-US"
    IsNeutralCulture: false
    IsReadOnly: true
    KeyboardLayoutId: 1033
    LCID: 1033
    Name: "en-US"
    NativeName: "English (United States)"
    NumberFormat: {System.Globalization.NumberFormatInfo}
    OptionalCalendars: {System.Globalization.Calendar[2]}
    Parent: {en}
    TextInfo: {TextInfo - en-US}
    ThreeLetterISOLanguageName: "eng"
    ThreeLetterWindowsLanguageName: "ENU"
    TwoLetterISOLanguageName: "en"
    UseUserOverride: true

Answer 1

According to the documentation for the CultureInfo class:

Control Panel overrides

The user might choose to override some of the values associated with the current culture of Windows through the regional and language options portion of Control Panel. For example, the user might choose to display the date in a different format or to use a currency other than the default for the culture. In general, your applications should honor these user overrides.

If UseUserOverride is true and the specified culture matches the current culture of Windows, the CultureInfo uses those overrides, including user settings for the properties of the DateTimeFormatInfo instance returned by the DateTimeFormat property, and the properties of the NumberFormatInfo instance returned by the NumberFormat property.

By default, UseUserOverride is true, as you can see in your capture of the current culture.

To ignore Control Panel overrides and use the default settings for the en-US culture, call CultureInfo.GetCultureInfo(String) and assign the result to Thread.CurrentThread.CurrentCulture. According to the documentation for this method:

If name is the name of the current culture, the returned CultureInfo object does not reflect any user overrides. This makes the method suitable for server applications or tools that do not have a real user account on the system and that need to load multiple cultures efficiently.

Answer 2

The Culture refers to the arrangement of year - month - day. As for the format "yyyy-MM-dd" is a default format.(I maybe wrong but this is according to what I understand). So you may want to provide it with your custom format. Applying date format