What is the daylight saving time (DST) problem?

A. On August 8, 2005, the Energy Policy Act of 2005 was passed which changes the start and end dates of DST. The new rules state that DST will start the second Sunday of March and end the first Sunday of November. This means that in 2007, DST will start March 11 instead of April 1 and will end November 4 instead of October 28. The differences in these times are known as the delta time.

Windows Vista and Windows Longhorn Server have these updated dates as part of the OS; for Windows XP and Windows Server 2003, a fix is available as part of Windows Update or downloaded at http://support.microsoft.com/kb/931836. Support isn't available for other OSs, support is not available but you can manually add support by modifying the registry, which is described in the Microsoft articles at http://support.microsoft.com/kb/930688, http://support.microsoft.com/kb/928388/ and at http://support.microsoft.com/kb/914387.

The other challenge relates to Microsoft Exchange Server and Outlook. Exchange requires an update for calendaring via Collaboration Data Objects (CDO), which are used by Outlook Web Access (OWA). This update is required because a separate internal time zone table is used beyond what is part of the OS for the OWA calendaring. This update is available for Exchange 2003 at http://support.microsoft.com/kb/926666/ . For older Exchange systems, you need to contact Microsoft Customer Service and Support (CSS).

Another problem is that Exchange Server and Outlook clients store appointments differently. Microsoft Office Outlook 2007 is already DST-update aware, but it's still advisable to run the Outlook update tool because the download has improvements over that built into Outlook 2007.

A recurring appointment is stored with a time zone and the DST offset; however, if it's a single instance, then no time zone is stored, just a date and time in GMT format, which is calculated when the appointment is created and is based on the computer's time, the time zone, and DST information. Appointments might have been made during the delta time (i.e., previously not DST but is now) and therefore need to be updated. Two options are available: a client-side utility that each user can run is available from http://support.microsoft.com/kb/931667/ , or a version that can be run on the Exchange server to update multiple mailboxes at once is available from http://support.microsoft.com/kb/930879/en-us. The server tool is essentially the client tool with a wrapper to allow multiple-mailbox migration, so you need to consider additional factors (outlined below) when choosing which version to use.

Because recurring appointments have full time-zone and DST information stored with them, the tool can check the time-zone rules for the appointment and update only if the previous DST information is wrong. For single-instance appointments, however, there is no time-zone or DST information stored (pre-Outlook 2007), so the tool has to assume any appointments in the delta times need to be updated if they're not stamped. Note, only items that the user is the organizer for are updated.

So do you use the Outlook tool or the Exchange tool? The Exchange tool can update all users so no user actions are needed; however, you must communicate with clients in the form of an advance email/memo to ensure they know it's going to happen and explaining the fact that exceptions to recurring appointments that have been made in the past will be lost and to make sure there computers are DST patched if you don't centrally distribute the patch. You should also advise users to update their home computers to avoid appointments being created at home without the DST update.

Users that run the tool themselves have more control and can select which appointments to update. This control is useful if there could be a combination of appointments (i.e., some had the time zone change, some did not) of appointments. Suppose a user has appointments in the delta time zone (let's call them A and B). The user then applies the OS DST update and creates another appointment in the delta time period called C (this is set with the correct time since the OS has the update). All the appointments are single instance. Now the user runs the Outlook DST update tool, which will attempt to update A, B, and C because it has no way to tell which appointments were created with the DST update applied; obviously changing C would incorrectly modify it's time. If running the tool manually, the user may notice this appointment is OK and select to not update it. For this reason, you should apply the update to Exchange/Outlook as soon as possible after the OS update to avoid appointments being created in this delta time. I recommend that you read the Microsoft article "How to address the daylight saving time changes in 2007 by using the Time Zone Data Update Tool for Microsoft Office Outlook" at http://support.microsoft.com/kb/931667 , which has very good information about such situations.

As I mentioned earlier, be aware that exceptions to recurring appointments, for example where the time was changed for one instance of the recurring appointment, those past exceptions will be lost after running the tool, so back up exceptions if needed.

In terms of update order, you should apply the server OS DST update, then the client OS DST update, and quickly afterwards the Exchange/Outlook update. Any appointment that falls within the DST question period should be confirmed just to be sure!