ConvertFrom-JSON incorrectly deserializes dates to DateTime

When ConvertFrom-JSON guesses something in the input data can be converted to a DateTime, it (silently) does so.

But the conversion doesn’t correctly interprets some strings.

Steps to reproduce

I’m running this on a system that’s on UTC+2 (CEST).

Write-Host("PowerShell version: " + $PSVersionTable.PSVersion.ToString())
$date = "2020-09-07T09:44:13.769Z"
Write-Host ("Original string: " + $date)
Write-Host("Cast to Datetime: " + [datetime] $date)
$json = ('[{"start":"' + $date + '"}]') 
Write-Host("JSON data: " + $json)
$data = $json |  ConvertFrom-Json
Write-Host($data[0].start.GetType().Name + " resulting from ConvertFrom-JSON: " + $data[0].start)

Expected behavior

PowerShell version: 7.0.3
Original string: 2020-09-07T09:44:13.769Z
Cast to Datetime: 09/07/2020 11:44:13
JSON data: [{"start":"2020-09-07T09:44:13.769Z"}]
DateTime resulting from ConvertFrom-JSON: 09/07/2020 11:44:13

Actual behavior

PowerShell version: 7.0.3
Original string: 2020-09-07T09:44:13.769Z
Cast to Datetime: 09/07/2020 11:44:13
JSON data: [{"start":"2020-09-07T09:44:13.769Z"}]
DateTime resulting from ConvertFrom-JSON: 09/07/2020 09:44:13

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

The same issue is still present in 7.1.0-preview.6.

[mklement0]

Glad to hear it, @Szeraax; since thumbs-ups matter as a gauge of interest the community has in seeing a proposal implemented, I invite you to up-vote #13598

[mklement0]

Let’s take a step back:

Use of [datetime]:

• [datetime] has several inherent limitations:

  • It only specifies an absolute point in time if its .Kind is Utc.
  • With Local, it isn’t self-contained: that is, only in relationship to the local time zone does it imply an absolute point in time.
  • With Unspecified, it is an abstract point in time that is interpreted differently when you call .ToLocalTime() (assumed to be UTC) vs .ToUniversalTime() (assumed to be local).
  • In terms of default formatting, a Utc instance lacks any indication that the timestamp is indeed expressed in UTC.

• [datetimeoffset] overcomes these limitations, but for the sake of backward compatibility we’re stuck with [datetime] in many cases.

  • [datetimeoffset] doesn’t even have a proper PowerShell display format at the moment (just does Format-List) and also lacks proper integration with respect to serialization - see #3172

In short: If backward compatibility weren’t in the picture, [datetime] should be considered obsolete and replaced with [datetimeoffset].

---

[datetime] <string> vs. ConvertFrom-Json behavior

• I agree that these two behaviors differ is surprising, and that implementing something PowerShell-idiomatic justifies deviation from underlying API behavior.

• However, I find the behavior of [datetime] <string> ([datetime]::Parse(<string>, $null)) in itself counterintuitive behavior in that [datetime]::Parse('2020-01-01'), for instance, results in a instance with .Kind Unspecified rather than Local.

  • More sensibly, [datetimeoffset]::Parse('2020-01-01') assumes that the date is in the local time zone.

---

Given the need for backward compatibility, I don’t think we can change the current behavior, but what #13598 proposes should give you the desired functionality (asking that timestamps be normalized to UTC, local, or unspecified [datetime] or to [datetimeoffset] instances).