Customised Historical Report Timezone Problem on 8.x

[Unified Comms Guy]

Hi all,

I am currently having an issue with the gmtOffset fields in the UCCX 8.x database. All the records in "gmtOffset" field of the "AgentConnectionDetail", "AgentStateDetail" and "ContactCallDetail" table are always populated with a zero regardless of what timezone is selected for the Operating System or the UCCX Application (under system parameters).

This problem is causing my custom Historical Report to place all records at GMT time and not the local time.

Has anyone come across this problem before?

Thanks in advance.

Ben

[Ronald Reif]

We understand that in version 8, Cisco stopped filling the GMT offset fields.  They now record all time stamps for historical information in GMT time zone only.  This leaves the report designer to find their own offsets to local time depending on how they are writing their custom reports.  Our solution handles these new offsets and lets the users design their own reports that handle converting GMT to their local times.  Please contact me if you would like to know how we add value to this issue as well as many more enhancements.

Thanks,

Ron Reif

SMSI

651-8-635-2822

rreif@smsi.com

[octavian.dumitrescu]

Hi,

Do your standard reports display the correct timezone? Do you have this issue only with the customised ones?

If both standard and customised display UTC times then in your HR client you have an option in one of the menus to check (or uncheck) UTC.

If your standard reports display the correct time and your customised ones don't, then what I did was to modify the timezone directly on the hour field in the report template. If you have Cristal Reports just open one of the standard report templates and you will see there how is done.

Octavian

[Ronald Reif]

Both our Standard and Customized Reports reflect the locat time.

I am not sure regarding your question regarding the HR environment.  My developer is out of touch for a couple of days.  I will ping him and when I get an answer - I will respond.

Thanks

Ron Reif