where we are puling the time from, primary IC server, has the correct time, but the phone have jumped ahead a week early it seems. How\where do we check to determine when the phones are to spring forward? TIA Shurla

Originally posted by shurla5;36799
where we are puling the time from, primary IC server, has the correct time, but the phone have jumped ahead a week early it seems. How\where do we check to determine when the phones are to spring forward? TIA Shurla

Sorry - we are using Polycom IP 335 and 430s Shurla

I would first look at DHCP to see if Option 004 (Time Server) or Option 042 (NTP/SNTP server) is set to tell the phone where to get it's time setting. The Location settings under Regionalization also have a setting to tell entities whether to get their time from the IC server or another source, so check that setting in IA as well. Also, on the phone itself, press the Menu button, Status, TCP/IP Parameters, and scroll down to the SNTP Address - that should tell you where the phone is getting its time from.

Originally posted by GGanahl;36801
I would first look at DHCP to see if Option 004 (Time Server) or Option 042 (NTP/SNTP server) is set to tell the phone where to get it's time setting. The Location settings under Regionalization also have a setting to tell entities whether to get their time from the IC server or another source, so check that setting in IA as well. Also, on the phone itself, press the Menu button, Status, TCP/IP Parameters, and scroll down to the SNTP Address - that should tell you where the phone is getting its time from.

And all three of those locations have the correct time, just the phones are wrong. Thanks, Shurla

What does the GMT Offset show on the phone? Is that correct? (In Status just below the SNTP Server info)

I forgot to ask what version of IC...I have a memory of there being a problem withing the past few years of phones shifting to DST early...vague memory...

Originally posted by GGanahl;36804
I forgot to ask what version of IC...I have a memory of there being a problem withing the past few years of phones shifting to DST early...vague memory...

We have the same issue today, and the same last year at this time. Phones are Polycom VVX400 mostly. Server is 2016R4 patch 2. I am told a patch will fix it, but it seems this minor setting should be able to be adjusted. When I review the Polycom config files, they are correct. We have a few phones that are not managed, and because they use config files delivered via TFTP, they are fine. The month/date/start time of DST is correct. We had hoped we would be allowed to patch before this date, but budget didn't allow for it yet.

Originally posted by GGanahl;36803
What does the GMT Offset show on the phone? Is that correct? (In Status just below the SNTP Server info)

On the phone itself, SNTP is blank, and GMT offset is -0. So I don't think these values are displaying from the phone menu.

That just means they are not set by DHCP. So, it would go back to the Time Zone setting on the Managed IP Phone configuration and the Time Server setting in the Location.

Originally posted by GGanahl;36807
That just means they are not set by DHCP. So, it would go back to the Time Zone setting on the Managed IP Phone configuration and the Time Server setting in the Location.

This is set correctly. However, I can change it to a different time zone and restart the phone. This would be a workaround for us if we wanted to restart all of our phones tonight, and then again over the weekend....

We have this too 2016 R4 P5. As I understand this is fixed in patch 6 (or any other upgrade). I don't know the number of the KB article, but here is an excerpt: What is occurring is some versions of CIC are passing an incorrect value for Daylight Savings Time (DST) to the phone: tcpIpApp.sntp.daylightSavings.fixedDayEnable="0" tcpIpApp.sntp.daylightSavings.start.month="3" tcpIpApp.sntp.daylightSavings.start.date="1" This has been resolved IC-140435, where the parameter is changed to an 8 indicating the second Sunday of the month: tcpIpApp.sntp.daylightSavings.fixedDayEnable="0" tcpIpApp.sntp.daylightSavings.start.month="3" tcpIpApp.sntp.daylightSavings.start.date="8"

Originally posted by tcannon;36809
We have this too 2016 R4 P5. As I understand this is fixed in patch 6 (or any other upgrade). I don't know the number of the KB article, but here is an excerpt: What is occurring is some versions of CIC are passing an incorrect value for Daylight Savings Time (DST) to the phone: tcpIpApp.sntp.daylightSavings.fixedDayEnable="0" tcpIpApp.sntp.daylightSavings.start.month="3" tcpIpApp.sntp.daylightSavings.start.date="1" This has been resolved IC-140435, where the parameter is changed to an 8 indicating the second Sunday of the month: tcpIpApp.sntp.daylightSavings.fixedDayEnable="0" tcpIpApp.sntp.daylightSavings.start.month="3" tcpIpApp.sntp.daylightSavings.start.date="8"

Where would I find these settings? I can see them in our stand alone phones, but where does the provisioning server hold these settings? Thanks, Nicole

Originally posted by nofon4u;36810
Where would I find these settings? I can see them in our stand alone phones, but where does the provisioning server hold these settings? Thanks, Nicole

That's what I'm interested in seeing as well. Shurla

Originally posted by GGanahl;36807
That just means they are not set by DHCP. So, it would go back to the Time Zone setting on the Managed IP Phone configuration and the Time Server setting in the Location.

the time offset is set to 0. Yes it did happen either last year or the year before. We are running 2105 r3. Shurla

Originally posted by GGanahl;36807
That just means they are not set by DHCP. So, it would go back to the Time Zone setting on the Managed IP Phone configuration and the Time Server setting in the Location.

Can you all fix this please, so we don't do this next year, or give us the work around

We are running 2018 R1 Patch 5 and had the same issue, so i don't think it is corrected in a higher version. To correct in our network i simple did a reload from Managed IP Phones, which pushed the correct time, without causing any active calls to drop or the phone to reboot.

Every Year we have this can we please get a resolution

Originally posted by llneely;36814
Every Year we have this can we please get a resolution

AMEN to that! Shurla

Originally posted by shurla5;36816
AMEN to that! Shurla

If they wait a week we will forget about it :)

Originally posted by llneely;36818
If they wait a week we will forget about it :)

As mentioned by tcannon earlier in the thread, it was already fixed long ago. You have to upgrade to a newer patch or release.

Originally posted by GGanahl;36832
As mentioned by tcannon earlier in the thread, it was already fixed long ago. You have to upgrade to a newer patch or release.

Of course, Scott says he has the same problem in 2018 R1 p5, so quite possibly a regression along the way :-( Submit support tickets, make sure it is documented.

Originally posted by swilliams164;36813
We are running 2018 R1 Patch 5 and had the same issue, so i don't think it is corrected in a higher version. To correct in our network i simple did a reload from Managed IP Phones, which pushed the correct time, without causing any active calls to drop or the phone to reboot.

Very interesting, I've rebooted my phone multiple times but it doesn't change the time. Shurla

I used PolycomSim.exe to simulate registering one of the phones. Those configuration settings are in phone configuration file that is sent to the phones when they register.

Originally posted by swilliams164;36813
We are running 2018 R1 Patch 5 and had the same issue, so i don't think it is corrected in a higher version. To correct in our network i simple did a reload from Managed IP Phones, which pushed the correct time, without causing any active calls to drop or the phone to reboot.

2018 R1 had the same issue? Just a reload fixed it? No adjustment to time zone offset? Thanks, Nicole

Originally posted by nofon4u;36837
2018 R1 had the same issue? Just a reload fixed it? No adjustment to time zone offset? Thanks, Nicole

Yes that is all i had to do, i didn't make any other changes other then a reload the phones.