Allow obtaining original string value from ConvertFrom-Json returned DateTime

[dancojocaru2000]

Summary of the new feature / enhancement

As a user I want to be able to access the original string value of a converted DateTime so that it can be used in cases where an equivalent ISO 8601 representation would be considered a different value.

I am using an API which returns ISO 8601 strings as IDs. However, PowerShell automatically converts those IDs to DateTime, and using something like Get-Date -Format o $date returns a different string that results in a different, invalid ID.

Proposed technical implementation details (optional)

There are two ways I can see this implemented:

1. A -NoDateConversion flag to Convert-FromJson and cmdlets that use it such as Invoke-RestMethod
2. The returned DateTime could have an OriginalString member, so that the original string can be accessed like $date.OriginalString
3. The returned DateTime, when passed to Get-Date -Format o $date, would output the original string instead of a ISO 8601 equivalent reinterpretation.

[dwtaber]

Maybe this concept should be applied to other types the cmdlet converts from strings as well, rather than making DateTime a special case.

[iSazonov]

Please repro steps and input file example.

[dancojocaru2000]

Maybe this concept should be applied to other types the cmdlet converts from strings as well, rather than making DateTime a special case.

Agreed, DateTime was the first to get me in trouble so that's why I singled it out.

[dancojocaru2000]

Please repro steps and input file example.

$json = "[{`"id`": `"2022-03-09T09:11:04.254630+00:00`", `"otherData`": true}]"
$converted = ConvertFrom-Json $json
$converted[0].id | Get-Date -Format o

As can be seen, the input string is 2022-03-09T09:11:04.254630+00:00. The output of the last command on my machine is 2022-03-09T11:11:04.2546300+02:00. Since the two strings aren't identical, using the 2nd one as the ID results in an error.

I want to highlight that I don't want to obtain a +00:00 ISO 8601 string! It just so happens that this time the input is +00:00. If the input would be 2022-03-09T11:11:04.2546300+02:00 and the output would be 2022-03-09T09:11:04.254630+00:00, it would still be an error.

[iSazonov]

I see ConvertFrom-Json converts the string to local datetime. It is how underlying NewtonSoft.NET works. So we can not change this. You have to do some manual steps to convert local datetime to string you need.

[dancojocaru2000]

Is it not possible to somehow disable the automatic conversions and keep all strings as strings? Because this seems as a flaw to me (that should be perhaps fixed in NewtonSoft.NET), destructively converting data without an option to get the original back.

Edit: I found this Stack Overflow question: Json.NET Disable the deserialization on DateTime. Would it not possible to pass such options?

[iSazonov]

Edit: I found this Stack Overflow question: Json.NET Disable the deserialization on DateTime. Would it not possible to pass such options?

No, it will be huge breaking change.

Is your source string always in UTC? If yes, you could use an workaround otherwise it is a dead end.

[dancojocaru2000]

Why would it be a breaking change?

And no, the source string is not always following a certain format.

[iSazonov]

Why would it be a breaking change?

The cmdlet will return different result.

And no, the source string is not always following a certain format.

In the case you could pre-process the json so that "hide/mask" the datetime string.

[dancojocaru2000]

Why would it be a breaking change?

The cmdlet will return different result.

There could be a -NoConversion flag which would be a backwards compatible change.

[jborean93]

This is definitely possible to do without a breaking change. You can have an opt in parameter like -DateTimeFormat None|DateTime|DateTimeOffset that controls the DateParseHandling property in Newtonsoft. The default can be DateTime to preserve backwards compatibility if that is desired.

PowerShell already

PowerShell/src/Microsoft.PowerShell.Commands.Utility/commands/utility/WebCmdlet/JsonObject.cs

Lines 181 to 187 in 7dc4587

	new JsonSerializerSettings
	{
	// This TypeNameHandling setting is required to be secure.
	TypeNameHandling = TypeNameHandling.None,
	MetadataPropertyHandling = MetadataPropertyHandling.Ignore,
	MaxDepth = maxDepth
	});

passes in a settings class so it shouldn't be that hard to add. The only concern I would have is that it would tie ConvertFrom-Json more closely to Newtonsoft making it harder to potentially migrate to another JSON library in the future (if that's ever going to happen).

The current DateTime handling is a bit subpar because it always gives you a local kind DateTime object where you can loose information about the value like what TZ it was in. For example my local offset is +10:00 and this is what I see

$json = '"2022-03-09T09:11:04.25463+05:00"'
$converted = ConvertFrom-Json $json

$converted

# Wednesday, 9 March 2022 2:11:04 pm

$converted.Kind
# Local

I have no way to know with this deserialized value that the raw string had a +05:00 offset, I just know what the value is in UTC and local time.

[mklement0]

See also:

• Proposal: Add a -DateKind parameter to ConvertFrom-Json to control how System.DateTime / System.DateTimeOffset values are constructed #13598

• Relate discussion: ConvertFrom-JSON incorrectly deserializes dates to DateTime #13592

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

[kilasuit]

Reopening this for WG to review as I do think this is a bug as there shouldn't be a conversion unless the user requests one, which may deviate from current experience but would be reasonable to change going forward.