Daylight Saving Time
In case you have not noticed, the latest Daylight Saving Time (DST) change has had the virtual equivalent effect of Y2K, if not more so. The US Governments’ decision to change the dates for DST (Energy Policy Act of 2005) have had an enormous effect on everything from general productivity to huge IT department headaches to get various devices (computers, peripherals, etc) updated. Theoretically this is intended to save energy, but we believe that it really is an economic initiative in disguise. There are huge statistics that show that consumers spend more money when the sun is still up…. When the sun sets, people tend to go home…. Please excuse the editorial – there is actually a point to all this.
The DST change affects everyone’s calendar. Specifically, Calendar events created to occur within the window of time that was effected by the DST rule changes may be off by an hour when synched to other clients IF the operating systems AND the XC ‘connector’ version of the event creator has not been updated with the new time zone rules.
For the US and Canada, this means events with start or end dates between March 11 and April 1, 2007, will show up on other clients one hour earlier than specified and events with start or end dates between October 29 through November 4, 2007, will show up one hour later then specified.
For our European and Australian customers in time zones that have extended daylight saving time this year, any events with a start date between the original DST start date and the new, extended, one will synch events to other clients one hour earlier. This is also true for events with start dates that are after the original DST end date, as they will be one hour later then intended. Again, this only applies to events in the above date ranges that were created by a computer that had not been updated with the DST rule changes.
Some background: Our research indicated that the required operating system updates (Windows and OSX) would be available in the 4th quarter of 2006 meaning only events scheduled more then 4 months in advance would be effected. However, in actuality both Microsoft and Apple did not release their final updates until very recently causing a trickle down effect. To further complicate things, in Microsoft’s case, the initial updates contained some of the rule changes but not all.
The obvious question that arises is: ‘Why can’t Xchange Network just fix this?’. The reason we cannot automatically fix this problem is that all communication with the Xchange Network Server is done using UTC (GMT time without DST rules) times. When the client synchronizes events to the server it converts the event to UTC time using the time zone rules and methods provided by the operating system. The same process occurs in reverse when a client receives a calendar event as it translates the UTC times of the event to the local time, again using the operating system to perform the conversion. As a result, events created prior to the operating system or the XC connector being updated are not converted to the correct UTC time during the effected date ranges resulting in incorrect start and end times when synchronized to other clients.
If both clients have not been updated yet, then the translation occurs the same and the event appears properly on both clients. However, if one of the two clients has been updated and the other has not, then a discrepancy will appear which is why the core of the problem is the originator of an event.
For users that use the XC Connect web interface, if the server operating system has not been updated with the necessary changes, then events will be created and displayed one hour off during the effected date range as well. This is due to the web interface relying on the operating system for it’s time zone conversion rules like the clients do.
Due to the number of variables involved, we cannot simply provide a script to update all events to fix this problem since:
1. We do not know if the event was created by a client set to a time zone that had a rule change.
2. We do not know at what point the user’s operating system was updated to know whether any events that user created were translated to UTC time properly or not.
So, the next question obvious question is, ‘How can we fix this?’.
1. The first thing to do is ensure that you have installed the appropriate operating system updates on all of your clients:
For Windows, please see: http://support.microsoft.com/gp/cp_dst
For OS X, please see: http://docs.info.apple.com/article.html?artnum=305056
- for OSX 10.4: http://docs.info.apple.com/article.html?artnum=304586
- for OSX 10.3: http://docs.info.apple.com/article.html?artnum=304585
For our 10.2 users, the latest version of our OS X and Entourage connectors update the Java time zone settings as part of the installation process.
2. Secondly, make sure that your server has been updated to version 3.2.010 (the one referred to in our update e-mails). This server version includes the connectors required for step 3.
3. Next, please ensure that you are running the latest version of our connector software:
Outlook: 3.2.082
Entourage: 3.2.018
OS X: 3.2.021
Evolution: 3.2.003
4. Once the connectors and operating system are up to date, the last step is to investigate if you have any events that are incorrect, and if so, correct them.
There is a process for that, and we’d be happy to share it… contact us at support@xcnetwork.com if you need some help with it.