Best practices for DateTime serialization in .NET 3.5

Question

Some 4 years back, I followed this MSDN article for DateTime usage best practices for building a .Net client on .Net 1.1 and ASMX web services (with SQL 2000 server as the backend). I still remember the serialization issues I had with DateTime and the testing effort it took for servers in different time zones.

My questions is this: Is there a similar best practices document for some of the new technologies like WCF and SQL server 2008, especially with the addition of new datetime types for storing time zone aware info.

This is the environment:

1. SQL server 2008 on Pacific Time.
2. Web Services layer on a different time zone.
3. Clients could be using .Net 2.0 or .Net 3.5 on different time zones. If it makes it easy, we can force everyone to upgrade to .Net 3.5. :)

Any good suggestions/best practices for the data types to be used in each layer?

Prig

Answer 1

I think the best way of doing this is to always pass the object as UTC, and convert to local time on the clients. By doing so, there is a common reference point for all clients.

To convert to UTC, call ToUniversalTime on the DateTime object. Then, on the clients, call ToLocalTime to get it in their current time zone.

Candycecandystriped

Note that the client will receive the datetime kind as Unspecified. When you call ToUniversalTime on it, it will assume Local time and actually do a conversion. The correct way would be doing DateTime.SpecifyKind(myUtcTime, DateTimeKind.Utc) instead of ToUniversalTime. – Mastaba

Answer 2

One big issue is that WCF serialization doesn't support xs:Date. This is a big problem as if all you want is a date, you shouldn't be forced to be concerned about time zones. The following connect issue discusses some of the problems: http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215

If you want to represent a point in time unambiguously, i.e. not just the date part, you can use the DateTimeOffset class if you have .NET 3.5 on both client and server. Or for interoperability, always pass date/time values as UTC.

Thalassography

If you want to use DateTimeOffset and WCF, these two articles might be useful if you experience serialization issues: msdn.microsoft.com/en-us/library/ms730167(v=VS.90).aspx blogs.msdn.com/b/drnick/archive/2008/09/04/… – Ashien

as of 3/28/2013 link in Joe's post is broken. – Inelegant

Answer 3

UTC/GMT would be consistent in distributed environment.

One important thing is that specify the datetimeKind after populating your DateTime property with the value from database.

dateTimeValueUtcKind = DateTime.SpecifyKind(dateTimeValue, DateTimeKind.Utc);

See MSDN

Kamasutra

Answer 4

As long as your web services layer and client layer use the .NET DateTime type, it should serialize and deserialize properly as an SOAP-standard local date/time w/ Timezone information such as:

2008-09-15T13:14:36.9502109-05:00

If you absolutely, positively must know the timezone itself (i.e. the above could be Eastern Standard Time or Central Daylight Time), you need to create your own datatype which exposes those pieces as such:

[Serializable]
public sealed class MyDateTime
{
    public MyDateTime()
    {
        this.Now = DateTime.Now;
        this.IsDaylightSavingTime = this.Now.IsDaylightSavingTime();
        this.TimeZone = this.IsDaylightSavingTime
            ? System.TimeZone.CurrentTimeZone.DaylightName
            : System.TimeZone.CurrentTimeZone.StandardName;
    }

    public DateTime Now
    {
        get;

        set;
    }

    public string TimeZone
    {
        get;

        set;
    }

    public bool IsDaylightSavingTime
    {
        get;

        set;
    }
}

then your response would look like:

<Now>2008-09-15T13:34:08.0039447-05:00</Now>
<TimeZone>Central Daylight Time</TimeZone>
<IsDaylightSavingTime>true</IsDaylightSavingTime>

Leidaleiden

This is now how WCF seems to work. I don't get anything indicating time zone (i.e. -05:00). – Balanchine

Answer 5

I had good luck with just keeping the DateTime data type and always storing it as GMT. In each layer, I'd adjust the GMT value to the local value for the layer.

Halfblooded

Answer 6

For cases where the datetime object should simply stay the same use JsonConvert:

DateTime now = DateTime.Now;
string json = JsonConvert.SerializeObject(now);
DateTime nowJson = JsonConvert.DeserializeObject<DateTime>(json);

Alterable