| [EDIT] Realised this is the behavior I would expect. Parse is doing what I would expect it to, taking into account the given time being UTC. It's then returning an object that's in the local timezone. Still goes to show just how confusing this datetime stuff can be when even the expected behavior looks wrong. Wait… how is this not a bug according to both Microsoft's own spec[0] and ISO 8601[1]? The Z specifically means this time is in UTC. The behavior is not at all what I would expect from reading the docs [0]: > A string that includes time zone information and conforms to ISO 8601. In the following examples, the first string designates Coordinated Universal Time (UTC), and the second designates the time in a time zone that's seven hours earlier than UTC: > "2008-11-01T19:35:00.0000000Z" > "2008-11-01T19:35:00.0000000-07:00" [EDIT] I get it now: it's parsing it right, it's just that it's then putting it into a datetime object that's in the local timezone – which is what I would expect. The alternative would be counterintuitive to me. [0] https://docs.microsoft.com/en-us/dotnet/api/system.datetime.... [1] https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal... |
Further down the page:
> If s contains time zone information, this method returns a DateTime value whose Kind property is DateTimeKind.Local and converts the date and time in s to local time. Otherwise, it performs no time zone conversion and returns a DateTime value whose Kind property is DateTimeKind.Unspecified.