I guess it's because your DateTime
objects have DateTime.Kind
property equals to DateTimeKind.Unspecified
- it breaks all conversions between local and utc kinds. I mean some tool assumes that your DateTime is in Utc when it isn't really.
So just don't fight with the tools which have to guess the right kind of your DateTimes in the middle between you and your client. Just use UTC everywhere and convert to local only to show it to user.
Or, even better, use DateTimeOffset which is more suitable to deal with multizone times.. or even use Jon Skeet's NodaTime library which is a swiss knife for any time-related work (although, maybe it's an overkill for your case).
UPD. To answer the question from @Matthias Burger in comments below:
How would you work with dates like date of birth? I think "10.06.1991" could be a birthday. Means, in UTC his birthday were different than GMT - wouldn't it?
As always - it depends :)
As time is a tricky thing, you should be careful - and there is a great article from the Jon Skeet's blog about joys of date/time arithmetic. I know it's not a real answer, honestly, but there're too much different possible problem cases - do we need to compare dates, are they in the same calendar, do we assume that all people were born at midnight in local time zone and etc.
In already mentioned NodaTime
there's a concept of global and local instants (look at it's concepts page). I think for the most simple cases when we need to just store and show birthdays LocalDate
(local date instant) is enough. Even DateTime
is enough if you store local date and fixate the same time zone for all (so it'll be like you don't use time zone at all).
P.S. Btw, don't know if the last question was a check or not, but UTC is a standard and GMT is a time zone ;)