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:

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

# gabr on 14 Jan 2006 3:40 PM:

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

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

referenced by

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