Brother, can you spare a time[zone]?

by Michael S. Kaplan, published on 2006/01/14 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/01/14/512530.aspx


Ishan Bhalla asked in the microsoft.public.dotnet.internationalization newsgroup:

Hello everyone,

Is there any framework or API function i can use to get the date and time of  any city in the world?

Basically our server is based in Sydney and we need to know time in Perth when any scanning information comes from there. The server time is always Sydney time.

Thanks in advance
Ishan

Well, there are two functions that can be used to actually convert between Universal Coordinated Time (UTC) and the local time in a specific time zone, and they can be useful in situations where you cannot do this work on the client side where the user's settings can be the best guide for conversion.

They are SystemTimeToTzSpecificLocalTime and TzSpecificLocalTimeToSystemTime, each of which takes a pointer to a specific TIME_ZONE_INFORMATION structure to use for conversion (the first function has been around since Windows NT 3.5, while the second only since Windows XP).

Of course this only leads to more questions, since there is no function that retrieves a list of TIME_ZONE_INFORMATION structures to use (the only functions that support the structure are GetTimeZoneInformation and SetTimeZoneInformation and they deal with retrieving and setting the current time zone setting on a machine). You are left with either using undocumented registry keys or storing the time zone to use as it is reported by the client (note that the latter solution is a better one anyway since if the goal is towork with the client's settings then it is the only way to guarantee that you are in fact using the client's settings!).

And then of course there are all the issues about why Daylight Savings Time is not intuitive that Raymond Chen posted years ago in his blog (and internally long before that!).

Don't even get me started on the intense interest that some people have on adding time zone support to the .NET Framework that really has to be carefully planned out to make sure that it solves problems rather than causes them (or at least that it solves more problems than it causes!). I will talk more about this when there is more to talk about. :-)

There is some earlier mention I made of the Date and Time FAQ that helps explain a lot about the situation in the .NET Framework today -- a document that is very helpful for the managed side of this equation.

And I do owe people a fuller conversation on time zone support on Windows in general, which is coming....

 

This post brought to you by "" (U+0dde, a.k.a. SINHALA VOWEL SIGN KOMBUVA HAA GAYANUKITTA)


# gabr on 14 Jan 2006 4:08 AM:

An old article on time zones: http://www.thedelphimagazine.com/samples/1175/1175.htm

(in Delphi, but underlaying APIs and registry entries are same for all languages anyway)

# Michael S. Kaplan on 14 Jan 2006 1:12 PM:

Yes, I remember that one. Quite a nice article (the author and I share a cynical outlook!). The only real flaw is that it is so purely Delphi focused, which for some makes the code samples harder to follow.

# gabr on 14 Jan 2006 3:40 PM:

Well, I never did much work in C[++|#]. Pascal was my primary language and I do most of my programming in Delphi so ...

# Michael S. Kaplan on 14 Jan 2006 4:38 PM:

I know, I know. And I can follow it, it just makes it easy for people to dismiss it even though it is a really good piece.

# Maurits [MSFT] on 17 Jan 2006 5:01 PM:

The cheap solution is to store all dates in UTC+offset form

For example right now in my time zone it's:

Tue, 17 Jan 2006 14:01:35 -0800

referenced by

2008/06/29 Did someone break GetTimeZoneInformation in XP?

2006/05/24 Did somebody say time zones were intuitive?

go to newer or older post, or back to index or month or day