Time zone mess using WCF

Question

I have a SaaS system with multiple clients throughout the world. Each client is only in one time zone, though. Communication between client and my central server is done using WCF.

Now there's a scheduling aspect to the system, and times have to be stored in terms of the local time. But I am finding that when I send a class tagged with the DataContract attribute, having a DataMember property of type DateTime through the WCF interface, the system is getting too clever by a half, and it's translating the time to server time. OTOH, if I pass a DateTime value directly through a WCF interface as a parameter, the time comes through verbatim, as client time.

This is causing me a lot of headaches. Is there something I can configure somewhere so that the WCF service doesn't translate any times to local (server) time?

EDIT: Well, I don't know what I did, but I was working on some related stuff, and the problem appears simply to have disappeared! So I'd love to try out your answers, but I actually can't reproduce my own problem now... If I had time for the academic exercise, I'd look deeper, but right now, if it ain't broke...

Answer 1

WCF doesn't have any capability to automatically convert time values to UTC time. You could use and store the UTC time for your application. Of course, you'll need to undo this conversion when you're displaying these values in your UI.

Answer 2

I know that it's an old question, but if someone needs, here it is:

I suppose you do DateTime.Now in the client side. Instead of using this statement, use :

DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified)

It gets the local dateTime of the client and it will not change in the server.

Answer 3

Try using DateTimeOffset objects - the timezone offset is stored as well and if the time is translated you should be able to translate it back. You need .NET 3.5 or later.

You will have to change your code slightly as DateTimeOffset and DateTime cannot be cast to each other (they can be converted).

You shouldn't have to change Stored Procedure calls, but if you find the need, DateTimeOffset also exists in SQL Server.