I've been having an issue with Web API parsing datetimes incorrectly which I have tracked down to JSON.NET.
The issue is that if I send this datetime:
2015-07-28T19:06:01.000+00:00
in a JSON PUT request, the DateTime parsed in my model will be converted to a time in the local server timezone, with the C# datetime kind of local, not UTC.
If I send this datetime:
2015-07-28T19:06:01.000Z
It will correctly keep it as UTC, with the C# datetime kind of UTC which is what I want.
I can fix this, by setting the DateTimeZoneHandling like this:
SerializerSettings.DateTimeZoneHandling = DateTimeZoneHandling.Utc;
But I don't understand why it does this in the first place. According to ISO8601, Z and +00:00 should mean the same thing right? I'm worried about setting the DateTimeZomeHandling to UTC globally as I might not want every single date on my endpoint to be considered UTC.
Is there another setting where I can tell it to consider +00:00 to mean UTC?
答案 0 :(得分：3)
DateTime only distinguishes between UTC and Local (and Unknown). This causes all manner of problems considering that two different Local times could of course be local to two different zones, and a Local time could indeed be a UTC time if it's in a time zone that uses UTC (e.g. Iceland all the year long, or Ireland during the Winter). Because of this a DateTime could be Local and have a time difference to UTC of zero.
ISO 8601 on the otherhand (much more sensibly) either includes timezone information along with the date and/or time, or it doesn't.
There's no perfect way to roundtrip between the two, so considering Z to mean UTC and +00:00 to mean Local (but the sort of local that is identical to UTC) is an imperfect compromise to this situation, made a bit less imperfect by providing a DateTimeZoneHandling so that people can adjust from that compromise.
Using DateTimeOffset instead of DateTime is another way of dealing with the mismatch between DateTime and a combination of date, time and offset.