.NET 5 preview 4 broke DateTime::ToString()

[sba923]

(this originates from PowerShell/PowerShell#12755)

Description

Since .NET 5 Preview 4, the ToString() method in System.DateTime doesn't abide by the user's date/time formatting preferences.

Here's a simple program to repro this:

using System;

namespace DateTimeToString
{
    class Program
    {
        static void Main(string[] args)
        {
            string dotnetversion = System.Environment.Version.ToString();
            Console.WriteLine("dotnet version: {0}", dotnetversion);
            var now = System.DateTime.Now;
            string str = now.ToString();
            Console.WriteLine("DateTime.Now.ToString(): {0}", str);
        }
    }
}

And here's the output with previews 2 through 5:

Configuration

Windows 10 Pro x64 version 2004 build 19041.329
.NET 5 preview 4 (5.0.0-preview.4.20251.6) and above

Regression?

This is regression over .NET 5 preview 3 (5.0.0-preview.3.20214.6)

Other information

There's the output of the tests, as text:

Testing in: C:\tmp\dotnet5p2
  Version: 5.0.0-preview.2.20160.6
dotnet version: 5.0.0
DateTime.Now.ToString(): 2020-06-15 12:13:05
Testing in: C:\tmp\dotnet5p3
  Version: 5.0.0-preview.3.20214.6
dotnet version: 5.0.0
DateTime.Now.ToString(): 2020-06-15 12:13:06
Testing in: C:\tmp\dotnet5p4
  Version: 5.0.0-preview.4.20251.6
dotnet version: 5.0.0
DateTime.Now.ToString(): 6/15/2020 12:13:06 PM
Testing in: C:\tmp\dotnet5p5
 Version:   5.0.100-preview.5.20279.10
  Version: 5.0.0-preview.5.20278.1
dotnet version: 5.0.0
DateTime.Now.ToString(): 6/15/2020 12:13:07 PM

[iSazonov]

Please add full OS version.

[sba923]

Please add full OS version.

edited

[danmoseley]

What happens if you set DOTNET_SYSTEM_GLOBALIZATION_USENLS=true ? (https://docs.microsoft.com/en-us/dotnet/core/run-time-config/globalization)

cc @safern

[safern]

This is a dupe of:

#37121

You can change to use NLS as @danmosemsft described above or by adding a runtime configuration switch in your project:

https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu#using-nls-instead-of-icu

[sba923]

What happens if you set DOTNET_SYSTEM_GLOBALIZATION_USENLS=true ? (https://docs.microsoft.com/en-us/dotnet/core/run-time-config/globalization)

cc @safern

I used System.Globalization.UseNls = true which does the same according to https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu#using-nls-instead-of-icu (got the info first from @iSazonov in PowerShell/PowerShell#12755) and the problem goes away:

Note that this breaks PowerShell, and I'm not sure they will want to use NLS there--'cos IMVHO this would be a potential cause for PowerShell behaving differently on Windows and on other platforms.

Also, @safern claims in #37121 that this was fixed in Preview 5. This is not what I see... (see above).

[safern]

Also, @safern claims in #37121 that this was fixed in Preview 5. This is not what I see... (see above).

Actually I thought the issue that was reported was a dupe of: #35638 which is indeed fixed in Preview 5. For this issue you're reporting, I'm working on a fix and should have something out this week.

Thanks for reporting it.

[sba923]

You're very welcome.

For now, I might go for setting DOTNET_SYSTEM_GLOBALIZATION_USENLS=true in my global environment so that I get the expected behavior when running PowerShell 7.1 preview 3. Or I'll stick to using PowerShell 7.0.2 for any affected workloads.

[sba923]

Actually I thought the issue that was reported was a dupe of: #35638 which is indeed fixed in Preview 5. For this issue you're reporting, I'm working on a fix and should have something out this week.

Thanks for reporting it.

@safern So this issue should actually be reopened until you merge the fix in, correct?

[safern]

@sba923 sorry for the confusion. No, this is a dupe of: #37121

[sba923]

@sba923 sorry for the confusion. No, this is a dupe of: #37121

OK, now I get it right. This is indeed a duplicated of #37121, which is still open.