Skip Navigation LinksHome > View Post

DateTime in Web Services

Again, this came up in the newsgroups recently and it's a useful area to know more about if you use web services frequently. The question went along the lines of:
"What's the best way to deal with time zones? Should I convert all times to universal time (UTC) and then convert back in to Local time at the client?"

First, let us get quickly familiar with what UTC is.

Strangely, it actually stands for Coordinated Universal Time and is sometimes referred to as Zulu Time or Z time. Time zones around the world are expressed as positive and negative offsets from UTC. There's a great entry on wikipedia if you want the full lowdown.

.NET can deal with UTC and its DateTime struct has a ToUniversalTime() and ToLocalTime() method to switch between the two.

But what about DateTimes in Web Services?

Examine the following web method:

[WebMethod]
public DateTime[] GetDateTimes()
{
    return new DateTime[] {
        DateTime.Now,
        DateTime.Now.ToLocalTime(),
        DateTime.Now.ToUniversalTime() };
}

This simple method returns an array of three date times. The first is the current DateTime of the server, the second is the same time after ToLocalTime() has been called and the last is the same DateTime converted to UTC.

Now, I live in the UK which is currently at UTC so I changed the Time Zone on my server to be Moscow, or UTC +3 hours to make the example more interesting.

Let's have a look what the response from this web method looked like (grabbed using the excellent fiddler proxy):

<dateTime>2006-03-04T17:36:22.046875+03:00</dateTime>
<dateTime>2006-03-04T17:36:22.046875+03:00</dateTime>
<dateTime>2006-03-04T14:36:22.046875Z</dateTime>

You can see that the first two times are the same, because .NET grabs the local time when you use DateTime.Now so ToLocalTime() has no effect. Note that the date time contains additional information that could help you convert back to UTC time; it states that this time is 3 hours ahead of UTC: 2006-03-04T17:36:22.046875+03:00.

The last date time is 3 hours behind the other two, which is correct. Note how the UTC time ends in Z (Zulu Time, remember?).

OK - so far so good.

What happens when a client reads the response?

This is where it gets kind of interesting. I put together a Console application that called my web service (using a Visual Studio 2005 web reference) and displayed the three timings. Naturally, I ran the console app on a different machine and set the local time zone to UTC -2 hours (Mid-atlantic), which leaves a 5 hour gap between our two boxes.

Here is the results:

Results of the console web client:
04/03/2006 12:36:22
04/03/2006 12:36:22
04/03/2006 14:36:22

As you can see, the client has automatically converted the local (Moscow) time into local (Mid-atlantic) time. However, the Zulu time hasn't been altered at all!

I personally find this behaviour a little strange but forewarned is forearmed.

In summary

UTC times behave differently to Local times in web services (in .NET at least). Specifically, UTC times are untouched whereas local times are converted to the locale of the client.

One big takeaway from this article is that, whether you like it or not, your datetimes will contain some kind of time zone information. This isn't always what you want. For example, I work on a lot of systems that interact with Airlines and their flight timetables. As you're no doubt aware, most flight itineraries state that all times are local times (to the airport), e.g.

London - New York, departs 12:00 arrives 15:15

Obviously, the arrival and departure are local to each airport (unless concorde is back in action!).

If I was to carelessly represent this in a web service, it might look like this:

<departs>
    <location>London</location>
    <dateTime>2006-03-04T12:00:00.000000+00:00</dateTime>
</departs>
<arrives>
    <location>New York</location>
    <dateTime>2006-03-04T15:15:00.000000+00:00</dateTime>
</arrives>

Which is wrong. It doesn't arrive at 15:15 GMT (+0) it arrives at 15:15 Eastern Time (-5). For this reason, If I'm unable to provide the data in the correct format (because it's very difficult to know in which timezone a particular airport is) I always use a custom date time object, maybe like this:

<localTime year="2006" month="03" day="21" hour="15" minute="15" />

What was the question again?

Yes, got sidetracked there... "What's the best way to deal with time zones in Web Services? Should I convert all times to universal time (UTC) and then convert back in to Local time at the client?"

This approach should certainly work, but you could let .NET do all this for you if you just use the 'natural' server time. I guess my advice is to look at the options and decide which is most appropriate to your service. Personally I'd probably go with the approach you suggest and use Universal time. It's easy to convert back into local time, is more transparent (the data on the wire is the data you get) and there's no implicit conversion going on behind your back.

Tags: .NET

 
Josh Post By Josh Twist
7:31 AM
04 Mar 2006

» Next Post: Visual Notepad2
« Previous Post: DebugView from sysinternals

Comments are closed for this post.

Posted by Anders Lybecker @ 02 Apr 2006 11:19 PM
This is the correct behaviour of the DateTime methods. See http://msdn.microsoft.com/netframework/programming/bcl/faq/DateAndTimeFAQ.aspx#Question5

Posted by Ramalingam @ 04 Mar 2011 9:58 AM
i have two time zone of country(India,UK) reterive on country datetime to be retrived(India).

explain my problem

UK server database i have saved the UK timeZone server launched am browsing from india and seeing the Uk time i need to get the India how?

© 2005 - 2014 Josh Twist - All Rights Reserved.