Revised September 18, 2007

September 4, 2007

NOTICE:

THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTY OF MERCHANTABILITY. YOUR USE OF THE INFORMATION ON THE FIELD NOTICE OR MATERIALS LINKED FROM THE FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.

Problem Description

The operating systems of most Cisco products that support Daylight Saving Time (DST) have built in mechanisms to automatically change the times, based on current user-selected rules. Once the new DST is implemented, the time on devices that maintain time zone information will continue to change according to the old method, unless changes are made.

Impact to Networking Systems

Due to inconsistencies between time zones, New Zealand Daylight Saving Time changes may impact systems events as well as other management systems relating to problem escalation. Local time may be reflected in logs and on phone displays. Therefore, not having accurately represented local time is a very big concern for most organizations. This is especially true of systems that require accurate time and time stamping for proper operations.

Background

On April 30, 2007, the Minister of Internal Affairs issued a statement regarding a change in Daylight Saving Time policy for New Zealand. The change in policy has modified the start and end dates for Daylight Saving Time (DST). Beginning in 2007 and beyond, Daylight Saving Time in New Zealand will start on the last Sunday of September at 2:00 A.M. local time and end on the first Sunday of April at 3:00 A.M. local time.

Specifically for 2007-2008, Daylight Saving Time will begin at 2:00 A.M. local time on September 30, 2007, and end at 3:00 A.M. local time on April 6, 2008.

The old Daylight Saving Time policy dictated that DST started on the first Sunday in October and ended on the third Sunday in March.

Problem Symptoms

Impact to Networking Systems

Due to inconsistencies between time zones, NZ Daylight Saving Time changes may impact systems events as well as other management systems relating to problem escalation. Local time may be reflected in logs and on phone displays. Therefore, not having accurately represented local time is a very big concern for most organizations. This is especially true of systems that require accurate time and time stamping for proper operations.

Workaround/Solution

If implementing the patches is not an option, manual workarounds may be implemented. Follow the directions shown for the two dates. Once the appropriate patches are applied, the workaround must be undone to meet compliance with the new New Zealand DST dates.

September 30, 2007 recommendation (NZ):

- If the customer applied a Timezone Change workaround on September 30, 2007, such as required for Time of Day routing, that will need to be un-done on October 7, 2007.

- If the customer applied the Manual Clock Advance workaround on September 30, 2007, then:

For Cisco Unified Communication Manager 3.x or 4.x, sometime after 4:01 A.M. on October 7, 2007 it is necessary to re-check the "Automatically adjust clock for DST" box and manually set the server clock to the current local time on each Cisco Unified Communication Manager cluster node.

For Cisco Unified Communication Manager 5.x there is no customer access to the "Automatically adjust clock for DST" setting. The clock should have advanced ahead by one hour at 2:01 A.M. on September 30, 2007. To correct this, after 4:00 A.M. on October 7, 2007, the customer will need to manually set the server clock to the current local time on each Cisco Unified Communication Manager cluster node.

- If the customer fully patched the system for the September 30, 2007 DST start, there's no action required on October 7, 2007.

- If the customer did nothing in terms of patching or working around issues for the September 30, 2007 DST start, there's no action required on October 7, 2007. The clock would have been off by one hour starting at 2:00 A.M. on September 30, 2007, but this will automatically correct at 2:00 A.M. on October 7, 2007.

March 16, 2008 recommendation (NZ):

- If the customer applied a Timezone Change workaround on March 16, 2008, such as required for Time of Day routing, that will need to be un-done on April 6, 2008.

- If the customer applied the Manual Clock workaround on March 16, 2008, then:

For Cisco Unified Communication Manager 3.x or 4.x, sometime after 3:01 A.M. March 16, 2008 it is necessary to re-check the "Automatically adjust clock for DST" box and manually set the server clock to the current local time on each Cisco Unified Communication Manager cluster node.

For Cisco Unified Communication Manager 5.x there is no customer access to the "Automatically adjust clock for DST" setting. The clock should have fell back by one hour at 3:01 A.M. on March 16, 2008. To correct this, after 3:01 A.M. on April 6, 2008, the customer will need to manually set the server clock to the current local time on each Cisco Unified Communication Manager cluster node.

- If the customer fully patched the system for the September 30, 2007 DST start, there's no action required on March 16 or April 6, 2008

- If the customer did nothing in terms of patching or working around issues for the March 16, 2008 DST event (old end date) or after that date, there's no action required on April 6, 2008. The clock would have been off by one hour starting at 3:00 A.M. on March 16, 2008, but this will automatically correct at 3:00 A.M. on April 6, 2008, and would have been behind one hour between March 16 3:00 A.M. and April 6, 2008.

Daylight Saving Time Solution Overview

Depending on the configuration, there are up to three software items which may be required to make a Cisco Unified Communication Manager system Daylight Saving Time compliant.

Cisco Unified Communication Manager Releases

Cisco Unified IP Phone firmware loads

Windows 200x SR Patch

Cisco Unified Communication Manager service release (SR) update:

If any of these service releases or Engineering Special releases (ESs) are installed, then it is required that all nodes in the cluster are upgraded to the same service release or ES version.

The 7906, 7911, 7921, 7941, 7961, 7970, 7971 phones require a new phone load that incorporates the Daylight Saving Time changes. The necessary phone resolution for 2007 and higher New Zealand Daylight Saving Time is present in the following phone loads or Device Packages.

The Windows 2000 Daylight Saving Time patch is installed if any of these versions of MCS OSs are installed. All nodes are required to be on the same version. This patch affects Cisco Unified Communication Manager trace files timestamps and the time display on the server's console.

On or before Sunday September 30, uncheck Automatically adjust clock for Daylight Saving changes.

On September 30, 2007, on or after 3:01 A.M, move the clock forward one hour and then on October 7, after 3:01 A.M., check Automatically adjust clock for Daylight Saving changes.

If OS has not been updated prior to Sunday March 16, uncheck Automatically adjust clock for Daylight Saving changes prior to that date.

On April 4, after 03:01 A.M move the clock back one hour and after 03:01 A.M occurs again, check Automatically Adjust clock for Daylight Saving changes.

Please note, however, that manually adjusting the clock on Cisco Unified Communciation Manager servers could result in a conflict in time which may produce time synchronization issues. For instance, adjusting the clock during any active call would result in incorrect call duration records. Therefore, adjusting the clock is best to be done when fewest active calls are present.