PowerShell 7.1 preview 3 doesn't use configured date/time format

Created on 22 May 2020  路  71Comments  路  Source: PowerShell/PowerShell

This should speak for itself:

````

$PSVersionTable.PSVersion.ToString(); (Get-ItemProperty 'HKCU:Control PanelInternational' -name sTimeFormat).sTimeFormat; (Get-ItemProperty 'HKCU:Control PanelInternational' -name sShortDate).sShortDate; Get-Date -DisplayHint Time; Get-Date | ConvertTo-Csv
7.0.1
HH:mm:ss
yyyy-MM-dd

10:03:10
"DisplayHint","DateTime","Date","Day","DayOfWeek","DayOfYear","Hour","Kind","Millisecond","Minute","Month","Second","Ticks","TimeOfDay","Year"
"DateTime","Friday, May 22, 2020 10:03:10","2020-05-22 00:00:00","22","Friday","143","10","Local","179","3","5","10","637257385901795718","10:03:10.1795718","2020"

$PSVersionTable.PSVersion.ToString(); (Get-ItemProperty 'HKCU:Control PanelInternational' -name sTimeFormat).sTimeFormat; (Get-ItemProperty 'HKCU:Control PanelInternational' -name sShortDate).sShortDate; Get-Date -DisplayHint Time; Get-Date | ConvertTo-Csv
7.1.0-preview.3
HH:mm:ss
yyyy-MM-dd

10:03:37 AM
"DisplayHint","DateTime","Date","Day","DayOfWeek","DayOfYear","Hour","Kind","Millisecond","Minute","Month","Second","Ticks","TimeOfDay","Year"
"DateTime","Friday, May 22, 2020 10:03:37 AM","5/22/2020 12:00:00 AM","22","Friday","143","10","Local","61","3","5","37","637257386170614178","10:03:37.0614178","2020"

````

Steps to reproduce

  • use the standard en-US culture
  • set the time format to 24-hr HH:mm:ss and date format to yyyy-MM-dd via Settings
  • run Get-Date | ConvertTo-Csv

Expected behavior

Time is formatted using 24-hr format, date using specified yyyy-MM-dd format.

Actual behavior

Time is formatted in 12-hr am/pm format, date using M/dd/yyyy format

Environment data

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.0-preview.3
PSEdition                      Core
GitCommitId                    7.1.0-preview.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

Issue-Question Resolution-Fixed Waiting - DotNetCore

Most helpful comment

The .NET folks marked my issue as a duplicate of dotnet/runtime#37121, where @safern claims this was fixed for .NET 5 Preview 5--not what I see...

That claim from my side was initially wrong as I thought https://github.com/dotnet/runtime/issues/37121 was a dupe of https://github.com/dotnet/runtime/issues/35638 which was fixed in Preview5. I expect to have a fix for https://github.com/dotnet/runtime/issues/37121 this week and hopefully will be able to port it to Preview6 on time.

All 71 comments

Is this behaviour new in the latest preview or has it always been this way?

I would say it's new in preview 3. Too bad, I've just upgraded my last system, so I don't have any preview 2 system anymore.

We'll need to confirm if there was a change at some point or if this is the original behaviour.

Also, can you confirm if this is affected at all by using the -UseCulture parameter explicitly?

We use Datetime.ToLongTimeString() method for output in the case.
Also you could look (Get-Culture).DateTimeFormat.

In 7.0.1:

````

$PSVersionTable.PSVersion.ToString(); (Get-Culture).DateTimeFormat
7.0.1

AMDesignator : AM
Calendar : System.Globalization.GregorianCalendar
DateSeparator : -
FirstDayOfWeek : Monday
CalendarWeekRule : FirstDay
FullDateTimePattern : dddd, MMMM d, yyyy HH:mm:ss
LongDatePattern : dddd, MMMM d, yyyy
LongTimePattern : HH:mm:ss
MonthDayPattern : MMMM d
PMDesignator : PM
RFC1123Pattern : ddd, dd MMM yyyy HH':'mm':'ss 'GMT'
ShortDatePattern : yyyy-MM-dd
ShortTimePattern : HH:mm
SortableDateTimePattern : yyyy'-'MM'-'dd'T'HH':'mm':'ss
TimeSeparator : :
UniversalSortableDateTimePattern : yyyy'-'MM'-'dd HH':'mm':'ss'Z'
YearMonthPattern : MMMM yyyy
AbbreviatedDayNames : {Sun, Mon, Tue, Wed鈥
ShortestDayNames : {Su, Mo, Tu, We鈥
DayNames : {Sunday, Monday, Tuesday, Wednesday鈥
AbbreviatedMonthNames : {Jan, Feb, Mar, Apr鈥
MonthNames : {January, February, March, April鈥
IsReadOnly : True
NativeCalendarName : Gregorian Calendar
AbbreviatedMonthGenitiveNames : {Jan, Feb, Mar, Apr鈥
MonthGenitiveNames : {January, February, March, April鈥
````

In 7.1 preview 3:

````

$PSVersionTable.PSVersion.ToString(); (Get-Culture).DateTimeFormat
7.1.0-preview.3

AMDesignator : AM
Calendar : System.Globalization.GregorianCalendar
DateSeparator : /
FirstDayOfWeek : Sunday
CalendarWeekRule : FirstDay
FullDateTimePattern : dddd, MMMM d, yyyy h:mm:ss tt
LongDatePattern : dddd, MMMM d, yyyy
LongTimePattern : h:mm:ss tt
MonthDayPattern : MMMM d
PMDesignator : PM
RFC1123Pattern : ddd, dd MMM yyyy HH':'mm':'ss 'GMT'
ShortDatePattern : M/d/yyyy
ShortTimePattern : h:mm tt
SortableDateTimePattern : yyyy'-'MM'-'dd'T'HH':'mm':'ss
TimeSeparator : :
UniversalSortableDateTimePattern : yyyy'-'MM'-'dd HH':'mm':'ss'Z'
YearMonthPattern : MMMM yyyy
AbbreviatedDayNames : {Sun, Mon, Tue, Wed鈥
ShortestDayNames : {S, M, T, W鈥
DayNames : {Sunday, Monday, Tuesday, Wednesday鈥
AbbreviatedMonthNames : {Jan, Feb, Mar, Apr鈥
MonthNames : {January, February, March, April鈥
IsReadOnly : True
NativeCalendarName : Gregorian Calendar
AbbreviatedMonthGenitiveNames : {Jan, Feb, Mar, Apr鈥
MonthGenitiveNames : {January, February, March, April鈥
````

We'll need to confirm if there was a change at some point or if this is the original behaviour.

Also, can you confirm if this is affected at all by using the -UseCulture parameter explicitly?

````

$PSVersionTable.PSVersion.ToString(); Get-Date | ConvertTo-Csv -UseCulture
7.0.1
"DisplayHint","DateTime","Date","Day","DayOfWeek","DayOfYear","Hour","Kind","Millisecond","Minute","Month","Second","Ticks","TimeOfDay","Year"
"DateTime","Friday, May 22, 2020 19:33:59","2020-05-22 00:00:00","22","Friday","143","19","Local","174","33","5","59","637257728391742480","19:33:59.1742480","2020"

$PSVersionTable.PSVersion.ToString(); Get-Date | ConvertTo-Csv -UseCulture
7.1.0-preview.3
"DisplayHint","DateTime","Date","Day","DayOfWeek","DayOfYear","Hour","Kind","Millisecond","Minute","Month","Second","Ticks","TimeOfDay","Year"
"DateTime","Friday, May 22, 2020 7:34:45 PM","5/22/2020 12:00:00 AM","22","Friday","143","19","Local","63","34","5","45","637257728850632108","19:34:45.0632108","2020"

````

Looks like a regression indeed. @iSazonov do you know if there were any changes merged to this area of code since 7.1-p2? I can't recall any at the moment.

Perhaps it's a regression or change in .NET Core?

Here's what I get with preview 2 on the same system:

````

$PSVersionTable.PSVersion.ToString(); (Get-ItemProperty 'HKCU:Control PanelInternational' -name sTimeFormat).sTimeFormat; (Get-ItemProperty 'HKCU:Control PanelInternational' -name sShortDate).sShortDate; Get-Date -DisplayHint Time; Get-Date | ConvertTo-Csv
7.1.0-preview.2
HH:mm:ss
yyyy-MM-dd

19:42:05
"DisplayHint","DateTime","Date","Day","DayOfWeek","DayOfYear","Hour","Kind","Millisecond","Minute","Month","Second","Ticks","TimeOfDay","Year"
"DateTime","Friday, May 22, 2020 19:42:05","2020-05-22 00:00:00","22","Friday","143","19","Local","14","42","5","5","637257733250149958","19:42:05.0149958","2020"

$PSVersionTable.PSVersion.ToString(); Get-Date | ConvertTo-Csv -UseCulture
7.1.0-preview.2
"DisplayHint","DateTime","Date","Day","DayOfWeek","DayOfYear","Hour","Kind","Millisecond","Minute","Month","Second","Ticks","TimeOfDay","Year"
"DateTime","Friday, May 22, 2020 19:42:40","2020-05-22 00:00:00","22","Friday","143","19","Local","847","42","5","40","637257733608470239","19:42:40.8470239","2020"
````

I can not confirm. After I changed these format strings in registry and restarted PowerShell I get right outputs.

What? Where was changing the format strings in the registry mentioned here? 馃槙

To get things right I uninstalled preview 3 and installed preview 2

馃槣

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

I don't understand: there is an issue in preview 3, it has to be fixed!

I can repo. We need reliable repo steps.
You could download zip packages, install PowerShell side-by-side, run both version and check result (better on clean system).

You mean you can't repro?

I don't have a clean system to test on (could set up a test VM, but would take a significant amount of time).

I'll test with XCOPY-deployed SxS installations of preview 2 and preview 3.

Here's the outcome, using these launch scripts:

REM runpwsh.bat cls PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem .\pwsh -noprofile -file .\runtest.ps1

````

runtest.ps1

$PSVersionTable.PSVersion.ToString()
(Get-ItemProperty 'HKCU:Control PanelInternational' -name sTimeFormat).sTimeFormat
(Get-ItemProperty 'HKCU:Control PanelInternational' -name sShortDate).sShortDate
Get-Date -DisplayHint Time
Get-Date | ConvertTo-Csv
````

image

image

Repro'ed on two different systems.

What is output:

$Host

(Get-Culture).DateTimeFormat

On preview 2:

````
C:tmpPowerShell-7.1.0-preview.2-win-x64>PATH=C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem

C:tmpPowerShell-7.1.0-preview.2-win-x64>.pwsh -noprofile -file .runtest.ps1
7.1.0-preview.2

Name : ConsoleHost
Version : 7.1.0-preview.2
InstanceId : 91f11a8e-5486-4058-b1e8-9bb93bb9adc9
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-US
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace

AMDesignator : AM
Calendar : System.Globalization.GregorianCalendar
DateSeparator : -
FirstDayOfWeek : Monday
CalendarWeekRule : FirstDay
FullDateTimePattern : dddd, MMMM d, yyyy HH:mm:ss
LongDatePattern : dddd, MMMM d, yyyy
LongTimePattern : HH:mm:ss
MonthDayPattern : MMMM d
PMDesignator : PM
RFC1123Pattern : ddd, dd MMM yyyy HH':'mm':'ss 'GMT'
ShortDatePattern : yyyy-MM-dd
ShortTimePattern : HH:mm
SortableDateTimePattern : yyyy'-'MM'-'dd'T'HH':'mm':'ss
TimeSeparator : :
UniversalSortableDateTimePattern : yyyy'-'MM'-'dd HH':'mm':'ss'Z'
YearMonthPattern : MMMM yyyy
AbbreviatedDayNames : {Sun, Mon, Tue, Wed鈥
ShortestDayNames : {Su, Mo, Tu, We鈥
DayNames : {Sunday, Monday, Tuesday, Wednesday鈥
AbbreviatedMonthNames : {Jan, Feb, Mar, Apr鈥
MonthNames : {January, February, March, April鈥
IsReadOnly : True
NativeCalendarName : Gregorian Calendar
AbbreviatedMonthGenitiveNames : {Jan, Feb, Mar, Apr鈥
MonthGenitiveNames : {January, February, March, April鈥

````

On preview 3:

````
C:tmpPowerShell-7.1.0-preview.3-win-x64>PATH=C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem

C:tmpPowerShell-7.1.0-preview.3-win-x64>.pwsh -noprofile -file .runtest.ps1
7.1.0-preview.3

Name : ConsoleHost
Version : 7.1.0-preview.3
InstanceId : 9244eab6-c591-4b06-9148-719bc5cba22d
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-US
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace

AMDesignator : AM
Calendar : System.Globalization.GregorianCalendar
DateSeparator : /
FirstDayOfWeek : Sunday
CalendarWeekRule : FirstDay
FullDateTimePattern : dddd, MMMM d, yyyy h:mm:ss tt
LongDatePattern : dddd, MMMM d, yyyy
LongTimePattern : h:mm:ss tt
MonthDayPattern : MMMM d
PMDesignator : PM
RFC1123Pattern : ddd, dd MMM yyyy HH':'mm':'ss 'GMT'
ShortDatePattern : M/d/yyyy
ShortTimePattern : h:mm tt
SortableDateTimePattern : yyyy'-'MM'-'dd'T'HH':'mm':'ss
TimeSeparator : :
UniversalSortableDateTimePattern : yyyy'-'MM'-'dd HH':'mm':'ss'Z'
YearMonthPattern : MMMM yyyy
AbbreviatedDayNames : {Sun, Mon, Tue, Wed鈥
ShortestDayNames : {S, M, T, W鈥
DayNames : {Sunday, Monday, Tuesday, Wednesday鈥
AbbreviatedMonthNames : {Jan, Feb, Mar, Apr鈥
MonthNames : {January, February, March, April鈥
IsReadOnly : True
NativeCalendarName : Gregorian Calendar
AbbreviatedMonthGenitiveNames : {Jan, Feb, Mar, Apr鈥
MonthGenitiveNames : {January, February, March, April鈥

````

What is time you change the datetime format?

The PowerShell versions use different .Net 5 Preview - 3 and 4.
You could download nightly build (it is on .Net 5.0 Preview5) and check again.
If you will see the issue you could discuss this in .Net Runtime repo.

I'm not sure I understand your question. When did I change the datetime format? That must've been when I installed the systems in the first place, 'cos as a software engineer I prefer 1) the English UI, so I changed the display language to English (my computers came with French Windows) 2) the ISO8601 YYYY-MM-DD date format. So I've probably never run any version of PowerShell with the default en-US date/time formats.

Where can I get the nightly builds from?

What is the .NET Core API that's used by PowerShell Core to convert a date/time to string? I need this information if I want to open an issue on .NET 5.0.

You can download night build from main page of the repository.

PowerShell uses Datetime.ToLongTimeString() method. All formats you get above with (Get-Culture).DateTimeFormat.

On that main page, I can see the status of the nightly builds in CI, but no download links. Am I missing something?

I'll try creating a C# test program and run it with various previous versions of .NET 5.

Press on the status icon and look artifacts under "Build for Windows".

Same repro:

image

The code that handles this is here:

https://github.com/PowerShell/PowerShell/blob/b1e998046e12ebe5da9dee479f20d479aa2256d7/src/Microsoft.PowerShell.Commands.Utility/commands/utility/CsvCommands.cs#L1045-L1067

With this code in mind, can you check what you get back for (Get-Date).ToString() and (Get-Date).PSObject.ToString()?

I'm reopening this as it doesn't look like we've gotten to the bottom of it yet. 馃檪

image

image

image

What's the easy way to create a C# program that invokes that .ToString() method and run it under various previews of .NET 5?

馃 OK, that _definitely_ looks like a regression in .NET 5 then, nice find.

Dunno if there's an easy way, but you can specify which preview to run against with usually a global.json in the project folder; you can see an example in the global.json in this repo. 馃檪

If you can figure out which preview broke the ToString() behaviour, definitely worth opening up an issue on the dotnet/runtime repository so we can get that fixed.

You will save time if you discuss with .Net Runtime experts.

That's what I want to do next... once I have found how to deploy the last 3 previews of .NET 5 side-by-side to run the C# test program against. I presume there are XCOPY-deployable zipfiles of those previews somewhere...

Can someone help me find those .NET bits (at least the versions used by PS7.1 preview 2 and preview 3)?

Maybe I'll just wait until preview 4, based on .NET 5 Preview 5, comes out, and test again there...

You can download nightly build - it is on .Net 5 Preview 5 already.

Good news!

But... when I reach https://powershell.visualstudio.com/PowerShell/_build/results?buildId=55455&view=artifacts&type=publishedArtifacts I get:

image

and clicking artifacts doesn't do anything. What am I doing wrong?

Sorry for sounding dumb, I'm definitely a GH CI rookie...

You can load nightly build from main page https://github.com/PowerShell/PowerShell#build-status-of-nightly-builds

GitHub
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

That's exactly what I've been trying to do, see
Can't download PS nightly build.zip

Try "Artifacts" - button on the right.

What "Artifacts" button on the right? Please refer to my PSR slideshow, or make a screenshot on your own.

I presume you wanted a ProcMon log of me reproducing the problem? Here it is, with preview 3.

runpwsh.bat.procmon.202006150911.PML.zip

@sba923 I still suggest to open new issue in .Net Runtime.

That's what I've been aiming at for some time now, but I can't unless I can post a repro. For this, I need to know how to get a side-by-side deployment of different previews of .NET 5, and then write a C# program I would run against each of those .NET previews. I haven't been able to find out how to download and deploy those previews. Yet...

Thanks for the hint.

But before I do this I'd like to test with a .NET 5 Preview 5-based build of PowerShell... ;-)

I think this is it ;-)

````
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);
}
}
}
````

gci -dir 'dotnet5p*' | % { $dotnetdir = $_.FullName "Testing in: " + $dotnetdir & ($dotnetdir + '\dotnet') --info | sls -raw 'Version:.*preview' & ($dotnetdir + '\dotnet') ($dotnetdir + '\DateTimeToString.dll') }

image

In procmon log I see an access to ICU - I guess the issue could be related to the fact.

It seems .Net has an option to opt out ICU. You could try and see a result.

Here's what I get with "System.Globalization.Invariant": true if this is what you were referring to:

image

Formatting is incorrect whatever the .NET 5 preview version.

No, there is an option to switch back from ICU to Windows traditional API.

See https://docs.microsoft.com/en-us/dotnet/core/run-time-config/globalization#nls

Learn about run-time settings that configure globalization aspects of a .NET Core app, for example, how it parses Japanese dates.

Will test... The change to use ICU was introduced in .NET 5 preview 4...

Bingo!

image

The .NET folks marked my issue as a duplicate of https://github.com/dotnet/runtime/issues/37121, where @safern claims this was fixed for .NET 5 Preview 5--not what I see...

Am I correct to assume that you will not want to use NLS in PowerShell? IMVHO this would be a potential cause for PowerShell behaving differently on Windows and on other platforms.

The .NET folks marked my issue as a duplicate of dotnet/runtime#37121, where @safern claims this was fixed for .NET 5 Preview 5--not what I see...

That claim from my side was initially wrong as I thought https://github.com/dotnet/runtime/issues/37121 was a dupe of https://github.com/dotnet/runtime/issues/35638 which was fixed in Preview5. I expect to have a fix for https://github.com/dotnet/runtime/issues/37121 this week and hopefully will be able to port it to Preview6 on time.

Am I correct to assume that you will not want to use NLS in PowerShell?

PowerShell follows .Net (and OS) improvements. It would be amazing for users to discover that PowerShell works differently than other .Net and native OS applications.

@iSazonov I'm not sure I know how to interpret your answer. Are you (on behalf of the PowerShell team) in favor of aligning PowerShell on Windows with all other Windows applications (in which case NLS is the norm), or of aligning PowerShell on Windows with PowerShell on other platforms (in which case ICU's behavior will rule)?

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 Since NLS and ICU have differences it can be a problem - one .Net application can work differently on different OS-es. MSFT has started to migrate to ICU. It was added in latest Window versions and .Net 5.0 uses ICU by default.
PowerShell 7.1 gets the enhancement automatically. The same is true for all .Net 5+ applications.

So you'll go for PS7.1 using ICU, and assuming this is backwards compatible e.g. abides by the user's settings, correct?

@sba923 7.1 will be on .Net 5.0. If the .Net will use ICU by default PowerShell will do the same.

Should be OK, provided this does not introduce severe breaking changes.

Expectedly, the issue is still present in 7.1 preview 4...

To give an update I have a PR out for the fix: https://github.com/dotnet/runtime/pull/38372

To give an update I have a PR out for the fix: dotnet/runtime#38372

Good! See my comment there about taking user changes into account on the fly. Does this need a code change on the PowerShell side of things?

If PowerShell 7.0 version sees the time (culture) changes immediately, then we get a breaking change.

If PowerShell 7.0 version sees the time (culture) changes immediately, then we get a breaking change.

How do you mean? That 7.1 should behave the same as 7.0? I don't know what 7.0's behavior is, but I _would expect_ that it takes user changes into account dynamically.

PS C:srct> ($PSVersionTable.PSVersion).ToString(),(Get-Culture).DateTimeFormat.ShortDatePattern
7.1.0-preview.3
M/d/yyyy

PS C:srct> ($PSVersionTable.PSVersion).ToString(),(Get-Culture).DateTimeFormat.ShortDatePattern
7.0.1
yyyy-MM-dd

.Net fix was merged. We get it soon. (.Net 5.0 Preview8)

.Net fix was merged. We get it soon. (.Net 5.0 Preview8)

What's the plan for testing? How difficult is it to make a private build of PS7.1 with that .NET fix in so that we can test for side effects / regressions ?

@sba923 You could build .Net locally and test. But it is not worth the effort. We can wait about a month.

Still waiting for .NET Preview 8 to be released...

PowerShell 7.1.0-preview.7 ships with .NET Preview 8, which should address this issue. Let us know if it hasn't.

I concur 馃槣

````

$PSVersionTable.PSVersion.ToString(); (Get-ItemProperty 'HKCU:Control PanelInternational' -name sTimeFormat).sTimeFormat; (Get-ItemProperty 'HKCU:Control PanelInternational' -name sShortDate).sShortDate; Get-Date -DisplayHint Time; Get-Date | ConvertTo-Csv
7.1.0-preview.7
HH:mm:ss
yyyy-MM-dd

18:08:34
"DisplayHint","DateTime","Date","Day","DayOfWeek","DayOfYear","Hour","Kind","Millisecond","Minute","Month","Second","Ticks","TimeOfDay","Year"
"DateTime","Thursday, September 10, 2020 18:08:35","2020-09-10 00:00:00","10","Thursday","254","18","Local","25","8","9","35","637353581150253074","18:08:35.0253074","2020"
````

Was this page helpful?
0 / 5 - 0 ratings