View source for TB/TB-2007-01-DST2007

[[TB]] -> '''TB-2007-01-DST2007'''
= 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 timezones changes. Changes of timezone 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 timezones used in North America are actually now each split into two subzones.

As Scalix Mail Server and its various clients store calendaring information in ways affected by timezone 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 timezone 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 timezone information tables from the underlying OS.

Therefore, as long as the timezone 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 timezone 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 [http://support.microsoft.com/kb/931836 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 timezone. Make sure that you select the correct timezone between Mexico and the rest of North America if you're located in one of the 3 timezones that are "split" after the change. Also make sure that your appointments were created in the "same" timezone.
==== 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 timezone 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.<br>'''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 timezones 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 [http://support.microsoft.com/kb/931667/ 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 timezone 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 timezone 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 summarised 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 timezone 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 timezone 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 timezone 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.

Please refer to the Scalix Forum or, if you are a commercial customer with an active support contract, to Scalix Support for further questions about the DST 2007 changes.