Yeah PowerShell has/has a number of oddball things like this. You can use "$(Get-Date -f x)" where the x can be any standard .net format code (d, G, etc). Both of the following were thankfully fixed in PS6+ as the defaults are much better now, but the ones I always got snagged on with PowerShell 5 were:  - Export-Csv forgetting to specify "-NoTypeInformation"  - Out-File without specifying "-Encoding Ascii" (the default used to be Unicode, now it's UTF8NoBOM) What always intrigues me though is observations that .net developers (vs sysadmins for example) often approach using PS from an API perspective, obviously from knowing the BCL API surface as we do so well. 😁 Conversely, sysadmin powershell will often look like WSH/wscript that they're more used to. e.g. for the timezones earlier, the Powershell-y way is something like:

get-timezone -list | where BaseUtcOffset -eq '09:30:00' | select DisplayName,SupportsDaylightSavingTime

DisplayName          SupportsDaylightSavingTime -----------          -------------------------- (UTC+09:30) Adelaide                       True (UTC+09:30) Darwin                        False Kudos to the folks at Microsoft for allowing each and any coding style to work regardless for everyone under the tent, of course! -Tony On 23/06/2022 18:10, Richard Carde via ozdotnet wrote:

I have no idea how widely known this is, but it annoyed me for an hour or so.

PS C:\> *(Get-Date).ToString()* 23/06/2022 2:06:24 PM

PS C:\> *"$(Get-Date)"* 06/23/2022 14:06:33

Huh?

I know why there's a difference.  Anyone been stung by that before?

The implicit conversion does this:

PS C:\> *(Get-Date).ToString($null,[System.Globalization.CultureInfo]::InvariantCulture)* 06/23/2022 14:07:43

Regards,

RC