US Daylight Saving Time Changes (2007)
Overview
The US Government has decided to extend the Daylight Saving Time (DST) as part of the Energy Policy Act of 2005. Starting in 2007, the DST period will be extended by 4 weeks in total, starting on March 11th (as compared to April 2nd in 2006) and ending on November 4th (as compared to October 28th in 2006).
This basically means that the definition of the 4 continental US time zones changes. Changes of time zone definitions have occurred quite frequently in the past. However, this is the first change affecting North America as a whole since IT systems with calendaring functionality have become widespread in use.
To further complicate things, Mexico is not implementing the change, while Canada is. Therefore, 3 of the 4 US time zones used in North America are actually now each split into two sub-zones.
As Scalix Mail Server and its various clients store calendaring information in ways affected by time zone definition, users of Scalix can be adversely affected by this DST change. This document explains the changes and points out possible solutions and workarounds.
In quick summary, Scalix calendaring users will be affected by the DST change for all appointments within the extended DST period, regardless of the client in use. For users of Outlook, Microsoft provides a tool that can fix most of the affected data automatically. In other scenarios, users will have to fix calendar appointments manually.
Description
In principle, time information for calendar appointments inside Scalix Mail Server is stored in or relative to Coordinated Universal Time (UTC). However, the UTC time information stored is calculated when the entry is created, based on the time zone information derived from the client operating system. This is true for both the Microsoft Outlook client running on Windows and the Scalix Web Access (SWA) client running within a browser environment, as the supported browsers (Internet Explorer and Firefox) both retrieve their time zone information tables from the underlying OS.
Therefore, as long as the time zone information on all clients is correct at time of storage and retrieval, appointments are displayed correctly. However, while the DST 2007 change was decided on in 2005, most operating system vendors have taken some time to implement the changes. In particular:
- Apple has rolled the time zone definition updates into the Mac OS/X 10.4.5 updated, published February 2006
- Linux updates for the tzdata/zoneinfo database are available through the respective OS vendor, but generally the changes for DST 2007 have been published in 2005 or 2006
- Microsoft has not pushed out the DST 2007 patch via Windows Update. However, a document and a patch are available. This is described in KB931836.
Consequences for Calendar data stored in Scalix
In general, you can consider various scenarios:
OS Update installed and calendar appointments created thereafter
This is the best case scenario. Appointments created after the OS has been updated will be stored and displayed correctly, given that the client workstation is set to use the correct time zone. Make sure that you select the correct time zone between Mexico and the rest of North America if you're located in one of the 3 time zones that are "split" after the change. Also make sure that your appointments were created in the "same" time zone.
OS Update installed, calendar appointments created before the update
In this case, when an appointment has been created before the OS update, appointments in the "changed" periods (i.e. between the "old" and "new" start dates of DST) will generally be off by one hour. When the appointment was created, the client system thought that DST would not yet be in effect on the respective date. For that reason, e.g. for PST a difference of 8 hours to UTC was put into the appointment. When the OS update is installed, however, the difference will have been corrected to only be 7 hours from (now PDT) to UTC. As a result, calendar appointments in March will be off by one hour.
OS Update not installed, calendar appointments created
In this case, the calendar entries will display correctly. However, during the extended DST period, the computers clock will be off by one hour. If the user manually corrects the clock, then calendar entries will again be off by one hour.
Multi-system scenarios and external data
In general, scenarios become more complex when data is created on one PC and looked at on another; also, other devices such as PDA's syncing to your desktop PC have their own idea of time zone information. As it is difficult to keep all these different sources in sync, it is highly likely that calendar entries will appear wrong during the extended DST period.
As a general statement, you should reconfirm all important appointments during the extended DST period manually.
Required Actions for Scalix
After all affected components have been updated, newly created calendar items will be interpreted correctly. Scalix itself does not make any assumptions about time zones of items, therefore no updates on the Scalix side are required.
If you're using Outlook, one thing that can be done to improve Outlook calendar data quality after the Windows OS upgrade has been installed is to run a tool provided by Microsoft and described in KB931667. This tool will try to identify and fix such entries automatically. It must be run individually by every user using Outlook. The server-side tool for Microsoft Exchange that is also described in the article cannot be used with Scalix.
For users using SWA, calendar entries will also be corrected if the tool is applied to the account using Windows and through Outlook. However, users not using Outlook at all cannot use the tool and will therefore need to manually fix their calendar entries during the extended DST period.
In general, the various scenarios for the tool are described in the Microsoft KB article referenced above. This is a short summary of how different types of calendar entries will be affected:
Single-instance calendar entries
In these entries, only a UTC offset is stored with start and end times. Some client versions have also included Location information (e.g. "Los Angeles") with the UTC offset. Quality of the automatic update will vary depending on the exact type of the time zone information, the location and the client software version used. The tool will fix many of these entries correctly.
Recurring calendar entries
In these cases, full symbolic time zone information is stored with the entry. Therefore, the tool will correctly update most of those entries. This is also true for exceptions stored within the recurrency pattern (i.e. one-offs)
Free/busy information
In Scalix, free/busy information is summarized and updated by the client. Therefore, the tool will not directly update free/busy information. However, as soon as the user logs into Scalix and adds or updates any entry to her or his calendar, free/busy information will be re-published and subsequently be up to date.
Meetings with Invitations
The tool only applies updates to meetings when the user using the tool is the meeting organizer. Also, when run for the meeting organizer, update notices to meeting participants will be sent automatically and will fix the recipients' calendar entries as well, if they are affected. However, for this to work properly, the participants' PCs will also need to be up-to-date with OS time zone information.
Resource Calendars
The tool can also be applied to resource calendars. However, this will be a manual operation and the resources calendar will have to be opened afterwards to update free/busy information.
Invites waiting for Acceptance
Meeting invitations still waiting in the Inbox will not be modified by the tool. However, if the operating system updates are applied, calendar entries should be created correctly from the invites. Therefore, invites should be accepted after the OS has been updated and after the tool has been run.
Summary
Based on the nature and the way calendaring information is stored by typical Scalix clients, it is very likely that some calendar information will be displayed incorrectly during the extended DST period. Therefore, extreme care must be taken when acting on this type of information. In general, as time zone information is most often processed on the client, it is of highest importance to make sure all affected client operating systems are upgraded correctly, so that objects created thereafter are stored and interpreted correctly. This includes mobile devices and all kinds of systems using data stored or generated by Scalix Mail Server.
Scalix itself does not contain time zone tables and therefore does not require any updates.
For users of Outlook, a Microsoft-provided tool can be used to fix some of the data affected by the DST change. Due to the nature and formats of the data stored, the results will not be 100% accurate, so some manual work will be required.