*** New Defect CSCsy25150 for DST

Unanswered Question
Mar 8th, 2009

Hi guys,

A quick update for DST


Certain models of Cisco IP Phones (first generation) fail to get the time information from tCisco Unified Communications Manager server component. Cisco IP Phone Models: 7920, 7960,7940,7921,7910,7936,7937,7912


Any first generation IP Phone registered to Cisco Unified Communication Manager 5.1.X and above where Daylight Savings Time changes are in affect.


1. Using CUCM Admin go to: System---Date / Time Group

2. Create new Date / Time group with one hour extra of local time.

3. Go to System --- Device pool

4. Create a New Device pool and assign the (one hour extra Date time group) to this device pool.

5. Assign the new Device pool to and Cisco IP Phones that are displaying the incorrect time.

We are working for a patch more updates soon

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (15 ratings)
rob.huffman Mon, 03/09/2009 - 05:57

Hey Gonz,

Thanks for taking the time out of your busy day to post this up! It is painful to see more DST problems creeping up, for sure. Especially on the "newest" CUCM Versions :(

Thanks for the "Heads-Up" buddy.

You Rock!


jasondrisc Mon, 03/09/2009 - 06:07


I would also like to tag in and add a big thanks for this post. Unfortunate situation, but I was able to apply the workaround before the majority of our users got in the office. Saved the Help Desk and myself a TON of phone calls.



luisrolocq Mon, 03/09/2009 - 12:21

Hi Jason

Do you mind leting me know how did you set up the time zone to have one hour ahead of regular time in the especified phones

alexjr Mon, 03/09/2009 - 06:39

I would also like to give a big thanks for the post. We noticed this problem this morning.

A customer would like to know when the patch is coming out. If you are able to post a date as soon as you know, I will greatly appreciate it. Thanks for your time again.

gonzalezel Mon, 03/09/2009 - 07:25

How would you add the extra local time. If I am in Central time would I just create a new time group in Eastern time to get that extra hour?

jasondrisc Mon, 03/09/2009 - 07:31

In our environment we have a lot of different device pools so what I did is changed the time zone reference directly in the date/time group and reset from there.

17roush Mon, 03/09/2009 - 07:40

That is what I had to do with select sites. But others I can not touch because they have a mixture of 7940s, 7941s, 7960s, and 7962s

astinus Mon, 03/09/2009 - 07:40

Is this related to a time of day partition routing issue as well? Have couple customers on 6.1.2 and 6.1.3 reporting that their time period/time schedule settings are off by an hour even though the server has the correct time.

jasondrisc Mon, 03/09/2009 - 08:00

I opened a TAC case after reading the initial thread in this conversation and this is the response I received:

The phones display wrong time because of this bug CSCsy25150 : 7960 and other phones incorrect time after DST on March 08,2009



Certain models of Cisco IP Phones fail to get the time information from the Cisco Unified Communications Manager server component.

Cisco IP Phone Models: 7905, 7910, 7912, 7920, 7921, 7925, 7935, 7936,7937, 7940, 7960

Time of Day routing will also be an hour behind.



Any first generation IP Phone registered to Cisco Unified Communication Manager 5.1.X and above where Daylight Savings Time changes are in affect.


Cisco Unified Communication Manager 5.1.X and above where Time of Day routing is being used



1. Using CUCM Admin go to: System---Date / Time Group

2. Create new Date / Time group with one hour extra of local time.

3. Go to System --- Device pool

4. Create a New Device pool and assign the (one hour extra Date time

group) to this device pool.

5. Assign the new Device pool to and Cisco IP Phones that are displaying

the incorrect time.

NOTE: This workaround action will need to be reversed on 03/15/2009 as the

CUCM time update will occur. Please plan to change your Device pools back


the original Date / Time group accordingly.


kelvin.blair Mon, 03/09/2009 - 08:25

Please advise.. I need to know if this includes the Time of Day Routing also. I've had some of my customers report issues with ToD routing. One customer in particular have the later model phones and phones had correct time. However, the TOD routing was not turning off correctly.

Also, another customer who is running the 7960's also reported the issue.

Please advise if this issue also effects the ToD schedules.


Michael Owuor Mon, 03/09/2009 - 08:34

Hi Kelvin,

Time of Day routing is indeed also affected by this issue.



kelvin.blair Mon, 03/09/2009 - 08:37

ok.. Now time to figure out how to just time the ToD schedules Time-Zone without affecting the phones. I have one customer where the time is correct on the phones but ToD is affected. In the earlier versions of CM, you could change the Time Zone by going to the time period. However,

I'm just now starting to look for it.. in 6.X and 7.X..

kelvin.blair Mon, 03/09/2009 - 08:39

ok.. made my change. For those who have the same problem. Change the timezone under the partition where the schedule is placed. This will fix the TOD problem until it is patched.

hauchinango Mon, 03/09/2009 - 07:46

I am getting tired of this!!!! Everytime the clocks change I end up looking incompetent. Enough of this!

jhindmarsh Mon, 03/09/2009 - 10:44

I agree. I thought we were done with this the last time they changed the DST rules!

mhendren925 Mon, 03/09/2009 - 10:49

I went ahead and did the workaround since I have less than 20 7940/60 phones out of the 500 phones here. No problem implementing it.

Matthew Bryant Mon, 03/09/2009 - 10:56

We can send a man to the moon 40 years ago, but we can't make a phone that changes its time during DST...

I have a huge amount of affected phones and all my device pools are set up by building and floor, so it would take a lot of work to redo these phones...any idea on a time line for a patch?

metuzuner Mon, 03/09/2009 - 11:28

Has Cisco been slacking lately? This is really bad for the reputation.

ealves-crhc Mon, 03/09/2009 - 12:13

It would seem that if you are running UCM Express then this fix would be a snap but if you have 500 + phones in multiple pools as well as MGCP devices then your sunk so much for 1/2 Million in SmartNet contracts. Come on TAC this issue has been in effect since 2005 it's 2009 and next year the DST time change happens March 14. What surprises do you have in store for us next year?

mightyking Mon, 03/09/2009 - 14:39

Hello All,

My issue is not with the phones but with the Time Period Routing and Time Schedule. Would the new page take care of this issue as well?



Lucas Phelps Mon, 03/09/2009 - 14:53

Agreed Matthew,

This workaround is a huge pain in the ass for us as well.

We've told our users to deal with the wrong time until the fix is released or until March 15th when it fixes itself (which will probably happen sooner than the fix is released).

luisrolocq Mon, 03/09/2009 - 12:08

Can you please let me know how do you manage the time to put one hour ahead? or do we need to use a time zone that has one hour ahead of local time. if that is the case wich one is it I don't seem to find a time zone that has only one hour ahead of me

luisrolocq Mon, 03/09/2009 - 12:41

Thanks for the replay

I have selected in the drop down menu the Atlantic Standard/Daylight Time - (GMT-4) but still no luck, all my 7940's and 60's are not updating after using the work around. I created the new group, i created the new device pool and assigned the affected phones to that poll for nothing.

Any sugestion to have this working till the patche is released

c.hulcher Mon, 03/09/2009 - 12:43

Did you reset the phones after assigning them to the new pool?

I reset my phones from CST/CDT to EST(Indiana) and after the reset the phones show the correct time.

ealves-crhc Mon, 03/09/2009 - 12:53

Sorry the info would have been predicated on what your UTC offset was to start with. I should have asked first.

ealves-crhc Mon, 03/09/2009 - 12:51

Have you reset the device pool?

As a test of this workaround we created a new pool IT-Test added selected test CP79x0 phones into the pool created new date time group called it No-EST set the time zone to Atlantic Standard/Daylight Time (GMT-04:00) Atlantic Time.

This fixed the x0 phones and broke the x1 phones

According to TAC engineer the x1 phones use UTC format x0 phones use UCM date/time group settings

luisrolocq Mon, 03/09/2009 - 15:01

Yes I have reset the new created Date/time group, the new device pool and the ip phones assigned to the new pool

still no luck

Just resuming to make sure i have followed the procedure correctly.

First, In call manager Administration page under system, Date time group we create a new Date time group whit a time zone 1 hour ahead of current time in my case i used Atlantic Standard/Daylight Time - (GMT-4:00)Atlantic

Second we create a new device pool and in the Roaming Sensitive Settings, under the option Date/Time group we use the new created Date/Time group

Third we go to the IP phones that have not updated and assign the new device pool, then reset the phone and acording to most of the users in this topyc, boom time gets updated. Well not in my case if i'm missing something i would really appreciate the help

loganseth Mon, 03/09/2009 - 12:55

Just wanted to extend my props to Gonzalo for the original posting. Like many others have posted, it saved us a bunch of time.

For us, we have 500 phones, mixed 40s, 60s, 70s, 41s, 61s, so while the conversion was not completely painless, this post helped us 'pull the band-aid off fast' rather than slowly over the course of the day.

So thank you, G, for the quick band-aid rip...now if only we could get Cisco to stop stabbing us in the leg...

Matthew Bryant Mon, 03/09/2009 - 13:22

I am in the same boat...

Plus, I am using those device pools to set up my paging zones for our IPCelerate paging server, so it would be chaos to try and make all those changes

Lucas Phelps Mon, 03/09/2009 - 15:16

The patch file is available for all versions of CommManager/CallManager 5.x to 7.x.

The patch file is the same for all the versions. However, to make sure you get the correct one, go to:

1) Support

2) Download Software

3) Voice and Unified Communications Software

4) To access Voice Software downloads, click HERE.

5) Expand IP Telephony > Call Control > Cisco Unified Communications Manager (CallManager) > Choose your version.

6) Then select 'Unified Communications Manager/CallManager Utilities'

7) Then expand the '1.1' folder and you will find the 'UCM COP Files'. This is your emergency patch. Read the release notes and apply.

Note: Requires a restart of the CCM service (drops calls)

gonzalezel Mon, 03/09/2009 - 14:25

What am I looking for to see if replication is working correctly?

rob.huffman Mon, 03/09/2009 - 16:17

Thanks Gonz!!

Your support here is superb as always! +5 points for your always helpful nature.



olighec Mon, 03/09/2009 - 17:18

Just applied the patch and it worked perfectly. My job would sure be a lot more difficult without Netpro!

luisrolocq Mon, 03/09/2009 - 18:16

Trying to apply the patch and when using RTMT to make sure that Database replication is working properly I'm not sure where to check to validate this,can you please give me a hand so I can verify that Database replications is working?

I have checked the logs and found one error with a service that was not running but after restarting the service no more error logs.

George Thomas Mon, 03/09/2009 - 19:04

If you are using 6.1 or higher you can view the replication status in Cisco Unified Reporting.

metuzuner Tue, 03/10/2009 - 04:57

Hi luisrolocq,

Login to RTMT and select 'Service -> Database Summary' from the CallManager menu up top. In the bottom of that screen you'll see a table where all the nodes in your cluster are listed. If replication status shows "2" for each node then replication is good. Also see below:

0 (Not Started)-No subscribers exist or the Database Layer Monitor service is not running and has not been running since the subscriber was installed.


1 (Started)-Replication is currently being setup.


2 (Finished)-Replication setup is completed and working.


3 (Broken)-Replication failed during setup and is not working.


4-Replication is not setup correctly.

Have a nice one.

mightyking Tue, 03/10/2009 - 06:46

Hello All,

My issue is not the phones because the phones are all 7941, 7961 and 7971. The issue is with the Time Period Routing and Time Schedule. Will the patch take care of this issue as well?



luisrolocq Tue, 03/10/2009 - 08:54

Thanks for your help, patch was a success and I'm up to speed again


This Discussion