Time on Partner ACS reverts two hours ahead after being reset manually

[JRTrevino]

Yo,

SO far I have three Partner ACS clients that have analog AT&T lines. Each client is reporting an issue that after they manually adjust the time on the system (Feature code #103), that the time automatically adjusts itself to be two hours ahead. One client claims that it adjusts after the first inbound call they recieve AFTER setting the time. When I called Catalyst, my distributor tech support, they told me that if the client has caller ID lines that they think that the timestamp is innacurate. They claimed that the system is trying to update the time from this timestamp, and suggested that I disable feature code #126 (Auto daylight savings time) and also contact the provider. One of the three clients had this feature enabled, so I disabled it, and reset the time, and I think they are good. The other two clients, however, already had #126 set to 2- Not Active so I called the provider to attempt to open a ticket with them. The AT&T rep that I spoke to was talking to me like I was "off my rocker" and was some loon that was playing a prank joke call or something.

IS there any validity to the claim that the system is clocking off the inbound caller ID call "time-stamp"??? And if so, why would the time still be auto-adjusting when the #126 feature is disabled- which I was told would fix the issue. One of the clients has a Partner ACS R8.0.12E. This processor has the "newer" daylight savings time schedule.

 

[JRTrevino]

SO I just got off the line with a different support engineer at Catalyst, who told me to default the system and reprogram it (this is for the R8 processor). For the R7 processors I had to open an Avaya ticket and get the patch from them. This sucks- this means that I will HAVE to buy PCMCIA cards, download the patch and deploy the cards to clients! WHY ARE WE FORCED TO PAY FOR ANYTHING THAT IS A KNOWN AVAYA SOFTWARE ISSUE?!?

 

[Telecomboy]

It's #128, Network Time Synch, you need to disable it on the R8 to resolve. For the R7, I don't think #128 was available yet, so you will need the patch they are refering to.

 

[Telecomboy]

It has nothing to do with Daylight Savings, it is the time being sent via caller id as Catalyst stated. They just gave you the wrong code. Once disabled, it will stop trying to synch with caller id.

 

[JRTrevino]

Thanks Telcomboy... I'll try that.

 

[retiredtelco]

I spent five days on and off the phone with AT&T, I was having the same problem, but with a R6 ACS processor. AT&T moved their caller ID data base to Illinois. Which is two hour ahead of Pacific Daylight Standard time. Somehow they forgot to program California into the equation. They are working to correct the time issue when Caller Id is sent to customer based systems.