3

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?

RodH257
  • 3,552
  • 5
  • 36
  • 46

1 Answers1

4

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.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
  • Great explanation! Thanks! It makes sense when you outline the comprimise, I couldn't find any JSON.NET docs on this - would be handy for them to add I guess. So instead of setting my json serializer settings I could use DateTimeOffset in my model, and it should stay at UTC? – RodH257 Jul 29 '15 at 01:21
  • If you use `DateTimeOffset` then the `UtcDateTime` property of the value will always give you the UTC time (and `LocalDateTime` will always be local to where the code is running, converting if necessary) so that's one approach. If there's a `DateTimeZoneHandling` option that fits your needs it will likely be simpler to use than that. If you possibly need to deal with different time zones and retain the time zone info then only `DateTimeOffset` will do that. – Jon Hanna Jul 29 '15 at 08:56