10-28-2016 02:29 AM - edited 03-19-2019 11:45 AM
We cave a CUCM ver 9.1 cluster. In the last week, and coincidental with a cluster reboot (a week before the timezone change) the time schedules have been behaving as if set to GMT rather than British daylight saving (i.e., kicking in an hour later than intended). This means that our out of hour messages are all offset by an hour and I can't find where the fault is since no changes have been made to the system NTP settings, phone NTP reference, system timezone settings, date/time group, or device pool date/time group settings.
The phone time LDC display settings is consistent with their device pool date/time group settings.
The Partition setting for the time schedules we use was set to originating device before the reboot & they worked fine. After the reboot schedules changes consistent with GMT not Daylight saving. No changes were made to the partition.
The system timezone is set as follows:
admin:show timezone config
Current timezone: British Summer Time (Europe/London)
Timezone version: 2013b
NTP status as follows:
admin:utils ntp status
ntpd (pid 29966) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 17 64 377 0.000 0.000 0.001
*10.xx.xx.xx 193.xx.xx.xx 2 u 291 1024 377 0.941 0.440 0.726
synchronised to NTP server (10.200.5.5) at stratum 3
time correct to within 86 ms
polling server every 1024 s
Current time in UTC is : Fri Oct 28 09:56:07 UTC 2016
Current time in Europe/London is : Fri Oct 28 10:56:07 BST 2016
The date/time group setting for the device pools are set to (GMT) Europe/London
If I change the Partition for a schedule programmed to start at 9.00 am, to any specific time zone of GMT + 1, it will kick in at 8.00 am, which is as expected. If I set the partition to a specific timezone of *any* of the GMT timezones the schedule will kick in at 10, which doesn't make sense. No matter what timezone setting I try for the schedule, I can't get it to kick off at 9.00 am.
The CUCM cluster reboot may/may not be a red herring. I'm now at a loss on this. It's almost has if the GMT timezone settings have all disappeared into the ether. Can anyone shed any light?
Solved! Go to Solution.
10-28-2016 11:13 AM
Hi Ron,
I think the issue is related to the "old" DST file on your CUCM this problem hit many people over the last weekend and the fix is described nicely in this recent Cisco doc;
https://supportforums.cisco.com/document/13149961/cucm-dst-time-change-t...
Cheers!
Rob
10-28-2016 11:13 AM
Hi Ron,
I think the issue is related to the "old" DST file on your CUCM this problem hit many people over the last weekend and the fix is described nicely in this recent Cisco doc;
https://supportforums.cisco.com/document/13149961/cucm-dst-time-change-t...
Cheers!
Rob
10-28-2016 11:52 AM
Hi Rob,
My problem is slightly different but I think you are correct. The problem will fix itself this Sunday but I'll apply the new DST file anyway.
Thanks,
Ron
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide