Get-IshBaselineItem parses incoming ModifiedOn and CreatedOn values using CurrentCulture instead resulting in Month Day swapping for some Regional Settings

[ddemeyer]

Problem...
Similar issue to #137 where all <ishfield> based values were corrected, however <object> based values, typical for Baseline Items retrieval was missed. See also SRQ-22720.

$p = Get-IshPublicationOutput -LogicalId GUID-1BC6D615-95BD-420E-B654-7E299EE84C78 | Out-GridView -PassThru  # selecting one row
$bi = Get-IshBaselineItem -Id $p.fishbaseline_version_element
$bi[0].ModifiedOn
Sunday, August 6, 2023 5:23:45 PM
$bi[0].ModifiedOnAsSortableDateTime
2023-08-06T17:23:45 # which is in the future at the time of writing

Workaround...
Use ([System.Globalization.CultureInfo]::CurrentCulture).DateTimeFormat.ShortDatePattern = "dd/MM/yyyy" in front of your PowerShell code. This operation will only set the ShortDatePattern for this PowerShell session, any new PowerShell session gets the system value again. It will make sure that the ISHRemote uses this CurrentCulture and parses DateTime objects correctly.

Suggested fix...

• Add GetIshBaselineItem.Tests.ps1 to at least test that the Set entry comes back from the server in the same way. Note that this test will always pass from day 13 to day 31 of the month because of the parsing fall back, but it should catch issues on day 1 to 12 as those could be parsed as months.
• Extract DateTime parsing from \HelperClasses\NameHelper.cs::GetPSNoteProperty into separate method HelperClasses\NameHelper.cs::TryParseDateTimeExact to reuse in GetPSNoteProperty method
• Add new TryParseDateTimeExact method in \Objects\Public\IshBaselineItem.cs::IshBaselineItem to no longer use implicit CurrentCulture for parsing CreatedOn and ModifiedOn properties.