There is a curious and strangely insidious problem associated with the change of the start of Daylight Savings Time. One thing that is counter intuitive for some is that just because information is stored in GMT for stuff like future appointments, it doesn’t mean that there won’t be problems when the time changes. The exact opposite is true. For instance, If you schedule a time in the future that is at 1pm, this might be translated to 7pm GMT. This would be -6 GMT according the time zone you are in. When the time zone changes, it really changes the relation to GMT, so perhaps it will be -5 GMT instead. When the application looks up the time for the appointment, after the time zone change it is actually 2pm, since it takes the 7pm and subtracts 5 from it because that is what the time zone information currently says.

The applications themselves need to track these kinds of issues, particularly scheduling applications like Exchange. Of course, the operating system needs to know the correct time for this all to work as well. Another issue is that the time zone is the particular computer’s perspective on time. Consider time synchronization. If a host thinks it is in a -6 time zone relative to GMT and the time server issues a GMT time, then if the time zone for everybody else is really -5, the user of that host will have a skewed perception of local time. Notice how there has been no mention of that Chicago song in this article whatsoever.

Any application that considers varying time zones can have problems. This includes programming languages that have their own time zone functions. Like the problem with the OS vs. the App, if your virtual machine or runtime environment is confused, it doesn’t matter if your application is running correctly. Another complication is that there are a variety of ways to patch the operating system, and some of these provide differing information to the application consuming the time zone information. For a discussion of how this interrelates, see Java Daylight Saving Time: Known problems and workarounds.

For Microsoft Windows specific information, see Daylight Saving Time Help and Support Center. For an alternative vendor for patching, one option is dst2007.

Let’s test the state of the start of Daylight Savings Time on an XP box:

C:\Documents and Settings\usr-9>systeminfo

Host Name:                 SRV-8
OS Name:                   Microsoft Windows XP Professional
OS Version:                5.1.2600 Service Pack 2 Build 2600
OS Manufacturer:           Microsoft Corporation
.
.
.
System Model:              OptiPlex GX240
System type:               X86-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: x86 Family 15 Model 1 Stepping 2 GenuineIntel ~
1694 Mhz

This is a fairly typical, if a bit old XP box we have in our lab. The registry setting that stores the start of DST is located in DaylightStart in HKEY_LOCAL_Machine\system\currentcontrolset\control\timezoneinformation:

This can be verified using the reg command:

C:\Documents and Settings\usr-9>reg query hklm\system\currentcontrolset\control\
timezoneinformation /v daylightstart

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\system\currentcontrolset\control\timezoneinformation
    daylightstart       REG_BINARY      00000400010002000000000000000000


C:\Documents and Settings\usr-9>

This corresponds to the first Sunday in April at 2am. Let’s patch the system via the KB928388 patch from Microsoft:

Now, when we run our query against DaylightStart, we get the new information:

C:\Documents and Settings\usr-9>reg query hklm\system\currentcontrolset\control\
timezoneinformation /v daylightstart

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\system\currentcontrolset\control\timezoneinformation
    daylightstart       REG_BINARY      00000300020002000000000000000000

C:\Documents and Settings\usr-9>

This now corresponds to the second Sunday in March at 2am. To test this, set the time to just before 2am on March 11:

When the time hits 2am, the clock will jump to 3am:

We also have a Windows 2003 server we would like to patch. The same reg utility can be used to view the registry information remotely. Let’s try:

C:\Documents and Settings\usr-9>reg query \\10.50.100.39\hklm\system\currentcont
rolset\control\timezoneinformation /v daylightstart

Error:  Access is denied.

We are not hitting a domain with the right credentials, we are simply logging on locally. We need to establish a security context with administrative rights on the remote server. Now, it turns out that the IPC trick still works, at least for a workstation without domain membership like we have:

C:\Documents and Settings\usr-9>net use \\10.50.100.39\ipc$ /user:administrator
The password or user name is invalid for \\10.50.100.39\ipc$.

Enter the password for 'administrator' to connect to '10.50.100.39':
The command completed successfully.

Let’s try our reg command again:

C:\Documents and Settings\usr-9>reg query \\10.50.100.39\hklm\system\currentcont
rolset\control\timezoneinformation /v daylightstart

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\system\currentcontrolset\control\timezoneinformation
    daylightstart       REG_BINARY      00000400010002000000000000000000


C:\Documents and Settings\usr-9>

We need to patch this server.