cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7387
Views
10
Helpful
27
Replies

DST 1 week early on 7940s

James Guthrie
Level 1
Level 1

Hi,

We're running Callmanager 8.5.1.12900-7 and I came in this morning to all our 7940s set an hour ahead.  I've checked and the callmanager server and NTP server are both correct and time zones are set correctly. 

I'm a bit confused, does anyone know if there is a patch or workaround for this?

James

1 Accepted Solution

Accepted Solutions

Hi Guys,

here is the information from Cisco Tac :

"

We are aware of this issue and have completed the testing across different CUCM versions.

The DST change dates have been updated in the latest timezone patch (2012j) that was released on 5-March 2013. To resolve the timezone problem, we need to install the latest timezone update on CUCM and perform a clusterwide reboot for the change to take effect.

The latest timezones update for CUCM is 2012j. this can be downloaded from the following link:

http://software.cisco.com/download/release.html?mdfid=283782839&flowid=26422&softwareid=282074298&release=8.6%282-2012j%29&relind=AVAILABLE&rellifecycle=&reltype=latest

For instructions regarding the installation procedure please refer to the readme file at:

http://www.cisco.com/web/software/282074298/100349/dst-862-2012j-cop-readme.pdf

We also have the alternative workaround of changing the Date/Time group to one that does not require a DST change. This will require a restart of all the phones as well to take effect. If you wish to go with this workaround, we will need to change the timezone in the Date/Time group again next weekend to reflect the correct timzeone for the IP phones.

"

Thierry

View solution in original post

27 Replies 27

Gary Parker
Level 1
Level 1

Hi, we're in the UK and seeing a similar issue.

A quick dash around the office this morning shows 6921, 6941 and 6961 are all an hour ahead.

7911, 7962 and 8961 are showing the correct time

69xx may (and should be) running SCCP as well.

I have reported this problem here time ago, but now I can't even find my own thread.

Paolo Bevilacqua wrote:

69xx may (and should be) running SCCP as well.

Are you saying we shouldn't we running SIP on the 69xx, or have I mis-understood ?

GTG

Please rate all helpful posts.

Jeff Clark
Level 1
Level 1

We have (had) the same issue this morning.

Call Manager 8.6.2 with a mix of 7940, 7942, 7945, 8945 and 9971 handsets. All but the 7942 and 9971 handsets were showing an hour ahead of the correct time.

Our Date/Time Group was set to use (GMT) Europe/London; we changed this to (GMT) Etc/Greenwich and restarted all handsets (633 of them!) which then came back up with the correct time, i.e. GMT not BST.

Feels like there's a bug in the device software of some phone models or even in the TimeZone itself? I'm sure Cisco will release a device software patch pretty soon.

Jeff

Jeff, changing the handsets to GMT would make them *not* subsequently change to BST, though.

Not sure about this as the previous setting was (GMT) Europe/London and has previously not had any problems changing from GMT to BST so surely changing from this to (GMT) Etc/Greenwich will not stop it working?

The only difference I can see between the two is compatbility for legacy handsets.

jeancouterie
Level 1
Level 1

hello,

We have the same issue in y company this morning in France, on 7912,7940 7960 and 7937.

7942 are ok

Jean

Hi guys,

Same problem here with some customers.

Phones 7940, 6921, 6941 ... are affected.

the 7942 are working fine
I am looking for a solution,

Thierry

You can find here the last patches for DST :

Downloads Home

Products

Voice and Unified Communications

IP Telephony

Unified Communications Platform

Cisco Unified Communications Manager (CallManager)

Cisco Unified Communications Manager Version 8.5

Unified Communications Manager / Cisco Unity Connection Time Zone Updates-8.5(1-2012j)

depending of your version of Callmanager.

The file was upload in march 2013 but when you read the readme, it seems to be a patch for the 2012 year.

I opened a service request for that problem

Thierry

Support Cisco
Level 1
Level 1

HI all,

Do you have tested to upgrade the dst with the last dst on Cisco Website

regards.

Vincent

Hi Vincent, could you point us to a download location for this DST file, please?

Guys,

We have the same issue too and we are on the phone with Cisco. Its affecting a  lot of Countries not just the UK. The issue is that CUCM DST went a week early. I will update you once we get a work around

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Support Cisco
Level 1
Level 1

hi,

in this location :

Unified Communications Manager / Cisco Unity Connection Time Zone Updates-8.5(1-2012j)

But i'm not sure that solution fixe your problem, but you can test another soltuion :

"If you are in CMT+1 you can configure Africa-Porto novo. This time zone is not affected and seems that works fine"

found in this post :

https://supportforums.cisco.com/message/3891739#3891739

regards.

Vincent

Hi Guys,

here is the information from Cisco Tac :

"

We are aware of this issue and have completed the testing across different CUCM versions.

The DST change dates have been updated in the latest timezone patch (2012j) that was released on 5-March 2013. To resolve the timezone problem, we need to install the latest timezone update on CUCM and perform a clusterwide reboot for the change to take effect.

The latest timezones update for CUCM is 2012j. this can be downloaded from the following link:

http://software.cisco.com/download/release.html?mdfid=283782839&flowid=26422&softwareid=282074298&release=8.6%282-2012j%29&relind=AVAILABLE&rellifecycle=&reltype=latest

For instructions regarding the installation procedure please refer to the readme file at:

http://www.cisco.com/web/software/282074298/100349/dst-862-2012j-cop-readme.pdf

We also have the alternative workaround of changing the Date/Time group to one that does not require a DST change. This will require a restart of all the phones as well to take effect. If you wish to go with this workaround, we will need to change the timezone in the Date/Time group again next weekend to reflect the correct timzeone for the IP phones.

"

Thierry