cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

CUCM : DST time change takes place a week in advance

3051
Views
30
Helpful
2
Comments

Introduction:

With the switch from DST to standard timing, we have noticed quite a few customers facing issues where their IP Phones moved from DST to standard time a week in advance.

Currently without the fix, the phones switch to standard timing on 23rd October 2016 which is a week ahead of the actual date ( 30th October 2016 ).

This article intends to provide complete information to our customers from diagnosing to fixing this issue incase they experience it.

Diagnosis:

To determine if we are hitting this issue, the first step is to run an sql query to check the dst date recorded in the database. 

admin:run sql select * from typetimezone where name="Europe/London"

 

enum name          description                                                  moniker                bias stddate              stdbias dstdate             dstbias abbreviation legacyname                

==== ============= ============================================================ ====================== ==== ==================== ======= =================== ======= ============ ==========================

21   Europe/London (GMT) Greenwich Mean Time; Dublin, Edinburgh, London, Lisbon TIMEZONE_EUROPE_LONDON 0    0/10/0/4,02:00:00:00 0       0/3/0/5,01:00:00:00 -60     GMT          GMT Standard/Daylight Time

 

Where:

 

  • stddate - Standard time start
  • dstdate - Summer time start
  • bias - Offset from GMT 
  • stdbias -  Offset from bias during standard time
  • dstbias - Offset from bias during summer time

Here 0/10/0/4 means Month/Day/Week : October/Sunday/4th Week

         0/3/0/5  means Month/Day/Week :  March/Sunday/5th Week 

Therefore per the output, the standard time start date is 0/10/0/4 which is 23rd October, 2:00 am.

This is the reason we would be seeing standard time starting a week before the actual date (30th October).

Fix for the issue:

The latest 2016d cop file includes the fix for this issue. It is available for UCM versions a) 11.5 

b) 10.5.2

c) 11.0

d) 9.1.2

Install the cop file on all the nodes in the clsuter, followed by the cluster reboot to resolve the issue.

Verification:

After installing the cop file followed by a cluster reboot the output of the same sql command would look like:

admin:run sql select * from typetimezone where name="Europe/London"

 

enum name          description                                                  moniker                bias stddate              stdbias dstdate             dstbias abbreviation legacyname                

==== ============= ============================================================ ====================== ==== ==================== ======= =================== ======= ============ ==========================

21   Europe/London (GMT) Greenwich Mean Time; Dublin, Edinburgh, London, Lisbon TIMEZONE_EUROPE_LONDON 0    0/10/0/5,02:00:00:00 0       0/3/0/4,01:00:00:00 -60     GMT          GMT Standard/Daylight Time

 

Where:

 

  • stddate - Standard time start
  • dstdate - Summer time start
  • bias - Offset from GMT 
  • stdbias -  Offset from bias during standard time
  • dstbias - Offset from bias during summer time

Here 0/10/0/5,02:00:00 means Month/Day/Week : October/Sunday/5th Week, 2:00:00 am.

After installing the fix, we see that the Standard time start is 0/10/0/5which translates to 30th October 2:00 am, which is the right Date.

Download links:

11.5

https://software.cisco.com/download/release.html?mdfid=286306100&flowid=79971&softwareid=282074298&release=2016d&relind=AVAILABLE&rellifecycle=&reltype=latest

11.0

https://software.cisco.com/download/release.html?mdfid=286284802&flowid=77897&softwareid=282074298&release=11.0(1-2016d)&relind=AVAILABLE&rellifecycle=&reltype=latest

10.5.2

https://software.cisco.com/download/release.html?mdfid=285963825&flowid=77896&softwareid=282074298&release=10.5(2-2016d)&relind=AVAILABLE&rellifecycle=&reltype=latest

9.1.2

https://software.cisco.com/download/release.html?mdfid=284510097&flowid=77894&softwareid=282074298&release=9.1(2-2016d)&relind=AVAILABLE&rellifecycle=&reltype=latest

NB: If your version of the Call Manager is not listed here, we need to either upgrade to a compatible version and then install the fix or use a timezone which follows the correct time till the 30th of October. 

Comments
Beginner

Beautiful my friend!!

I had these problem and I followed your instructions.

Thank you.

Beginner

Hi,

Sorry to be posting on this old thread but this is the most very helpful thread i found with the issue we are experiencing. 

In NZ DST starts on the last Sunday of September. But this year some of the older model of the phones started displaying incorrect time(1 hour ahead) a week earlier. Obviously i suppose this is because of 5 Sundays this month. we applied the latest DST patch and the issue has been resolved. However I have another query regarding this patch. Below 2 outputs are before and after applying the patch. First one has DST starting on 4th Sunday (which is not last Sunday of September this year). The second one has DST starting on 5th Sunday (Which is last Sunday of September this year). My query is, what happens in future when there are only 4 Sundays on the month of September. Year 2019 will probably not be an issue as it has 5 Sundays, but what about the year after that? Would we have to install another DST patch for that, or this output is specific to the query made at a particular date and time?

 

admin:run sql select * from typetimezone where name="Pacific/Auckland"
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ================ ================================ ========================= ==== =================== ======= =================== ======= ============ ==================================
51 Pacific/Auckland (GMT+12:00) Wellington, Auckland TIMEZONE_PACIFIC_AUCKLAND -720 0/4/0/1,03:00:00:00 0 0/9/0/4,02:00:00:00 -60 NZST New Zealand Standard/Daylight Time

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

admin:run sql select * from typetimezone where name="Pacific/Auckland"
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ================ ================================ ========================= ==== =================== ======= =================== ======= ============ ==================================
51 Pacific/Auckland (GMT+12:00) Wellington, Auckland TIMEZONE_PACIFIC_AUCKLAND -720 0/4/0/1,03:00:00:00 0 0/9/0/5,02:00:00:00 -60 NZST New Zealand Standard/Daylight Time

 

Your feedback will be much appreciated.

 

Regards

 

Bhola

 

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards