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
