WebServices and Timezone


Have you ever had to deal with consumer and provider of webservices residing in different time zones and one of the exchanges between them has to do with DateTime? If you have, then you probably know the output of the following piece of code. If not, I think its a good thing to know.


Let’s say we have a server in NY hosting a web service exposing the following web methods:



    [WebMethod]
    public DateTime GetServerTime()
    {
        return DateTime.Now;
    }


    [WebMethod]
    public DateTime GetClientTime(DateTime clientTime)
    {
        return clientTime;
    }


    [WebMethod]
    public string ReturnMyTime(DateTime clientTime)
    {
        return clientTime.ToString();
    }


 


The consumer of this Web service is in LA. We have a WSManager class which takes care of the communication with the web service. The consumer invokes the web services in the following way:



string serverTime = WSManager.GetServerTime().ToString();


string clientTime = WSManager.GetClientTime(DateTime.Now).ToString();


string clientTime = WSManager.ReturnMyTime(DateTime.Now);


Will there be any differences between the three strings? If yes, what will it be?


 


[Update]: Raymond talks about differences between Win32 and .NET’s way of dealing with TimeZones and Day light savings


[Update]: On a relevant note do you see any difference between the following two lines of code, where the attempt is to have a DateTime (dt1, dt2) in universal time following the statements:


DateTime dt1 = DateTime.UtcNow.AddDays(184)


DateTime dt2 =DateTime.Now.AddDays(184).ToUniversalTime().ToString()


[Update]: BCL Team’s blog on how the DateTime issues have been addressed in .NET 3.5 – A Brief History of DateTime and A Brief History of DateTime Follow-up


 

Comments (3)

  1. Jeff Parker says:

    Ohh, I have done this and I will turn you one better, not only crossing time zones but continents and the way this currently is will give you all kinds of funky things

    string serverTime = WSManager.GetServerTime().ToString();

    This will give you the server time, however the ToString will be in the culture of the client PC, also attached in the server time is the UTC offset so this will look like the client time.

    string clientTime = WSManager.GetClientTime(DateTime.Now).ToString();

    This will give you the time of the client PC and in the culture of the client PC so something the user will be used to.

    string clientTime = WSManager.ReturnMyTime(DateTime.Now);

    This one will probably make the user go WTF?!?!?! Depending on the culture of the server this will return time sent to it. In the servers culture and possibly the language and abreviations. This one kind of freaked me out the first time I did it.

  2. suryaj says:

    You are right. The key here is that the web services try to do the basic translation between the time zones provided you talk in DateTime. Once you start transliterating then you have to do plumbing work on either side of it.

    In short, I prefer webmethods 1 and 2 but not 3.

    Another thing I try to keep in mind while building applications which have DateTime as a parameter is make them talk UTC. That way you are in clear. It is kind of what XML is to distributed applications residing on diverse platforms.

  3. mattdotson says:

    Jeff, The culture info problem you describe can be overcome by flowing the client culture to the server … see http://www.w3.org/TR/2005/WD-ws-i18n-20050914/