Open up the help file and look up the .NET Framework DateTime structure.

Unfortunately the only time zone–related functionality provided is to convert local times to time in UTC (formally GMT; don’t ask me why this was changed!) and back again. This just works using the local time zone that the machine is currently running in. As the documentation states:

This method assumes that the current DateTime holds the local time value, and not a UTC time. Therefore, each time it is run, the current method performs the necessary modifications on the DateTime to derive the UTC time, whether the current DateTime holds the local time or not.

This method always uses the local time zone when making calculations. (Source: MSDN library)

Within the System namespace, there is a TimeZone class; let’s see whether that is useful for us.

All the documentation has to say about it is this:

A time zone is a geographical region in which the same standard time is used. (Source: MSDN library)

Not very verbose, but it sounds as though it might be promising.

If you examine the methods, you will discover that the constructor is protected, and the only way to create an instance of this class is to use the static property CurrentTimeZone. This is not very useful if we want to get the time zone information for different time zones.

(As another exercise, you can try to build a test application using the Time-Zone type and see whether you can get time zone for some other part of the world.)

Our next stop is to see what the Win32 API provides in terms of time zone functionality. A couple of functions look interesting: GetTimeZoneInformation and SetTimeZoneInformation. They both work with a TIME_ZONE_INFORMATION structure, which contains all the data that we need to build our application; for a given time zone, the fields in the structure are as shown in the following table.

This looks promising, but the methods only enable you to get or set the time zone on the local machine and retrieve time zone information about the time zone set on the local machine.

We are still stumped. We want to get time zone information for all the available time zones in the world. We figure it must be possible because the Control Panel extension that you use to set the Date and Time does it in the Time Zone tab.

That is the next place for us to look. If we could work out how the timedate.cpl (basically a DLL) worked, we could emulate that and get all the time zone information for around the world. So, first, we can look to see whether it exposes any form of interface (COM or .NET). You can try to open it using OLE View or ildasm, but no luck there; it supports neither a COM interface nor does it contain CLR header information.

Back to basics, open the CPL in Visual Studio as a resource to examine whether there are any clues in there. Maybe the time zone information might have been stored in the DLL (maybe in a string table).

Nope.

The only thing left we can think of is to open up the timedate.cpl file in a hex editor. (Yuck, I haven’t poked around inside Windows system files for a while; surely there’s a good reason for that!)

We begin this stage of the investigation by examining the DLLs that the code uses, all the usual suspects: KERNEL32, NTDLL.DLL, USER32.dll, COMCTL32.dll, ole32.dll, SHELL32.dll, GDI32.dll, ADVAPI32.dll, IMM32.dll and SHLWAPI.dll. Nothing of use here.

So carry on looking through the file for any other obvious clues; maybe the time zone data is hard coded in the DLL. Again no.

So where did the time zone information get stored? How about the Registry? Look for any references to Registry paths in the CPL file; you should find a few. The first ones lead to information about time synchronization via a timeserver and then some Registry entries for storing the current time zone settings for the local machine. Then about halfway down the file you can find a reference to the Registry key: SoftwareMicrosoftWindows NTCurrentVersionTime Zones.

Eureka!

This key contains a subkey for each time zone that is listed in the combo box in the second tab of the timedate.cpl. The data in each of the subkeys has to provide all the data required to build a TIME_ZONE_INFORMATION structure so that the application can set the time zone for the system. Now we just have work out how the data is formatted.

The string data is reasonably clear, as shown in the preceding table; we just need to work out how the byte data in the TZI (Time Zone Information) is stored. We start off by going back to the documentation on the structure, from which we can draw up the following table. So adding up the numbers, we are looking for 44 bytes of information, and the TZI value in the Registry is exactly 44 bytes long. Therefore, we must assume that we have all the data we need in the byte array. All we need to do is figure out which byte means what!

On your own, write a program that decodes the byte data in the TZI fields in the Registry, and try to work out how the time zone information data is stored in the TZI field. The best thing to do would be to write some tests that validate how we believe the time zone data is stored. We can run those tests when the OS changes and check whether the way time zone data is stored has changed.

You should have deduced the data was stored in the following order: Bias, Standard Bias, Daylight Bias, Standard Date, and Daylight Date. Okay, now we are ready to put together some code to use this information.

Below are some functions written in C# that use the time zone information from the Registry.

To populate a list with the available time zones, a static method on a class is shown first. It is static because it requires no instance data to be functional.

public static string[] GetTimeZones()
{
    RegistryKey regKey = Registry.LocalMachine;
    regKey = regKey.OpenSubKey(
        @"SOFTWAREMicrosoftWindows NTCurrentVersionTime Zones");
    return regKey.GetSubKeyNames();
}