Info Mart not observing DST

[PFCCWA]

Hello,

we have recently deployed Infomart however since the last daylight saving time change, records are showing as an hour less.  OCS/calling list has correct time (call_time field) however from point of etl to info mart it changes.
our date-time-tz setting is GMT.
the actual GMT timezone in CME has DST enabled.
no other component has been affected (except wfm which needs its own time step definitions).
I did not think we needed to make some extra configuration changes,
java is 1.7.

anyone else experienced this issue?

thanks.

[Kubig]

As I know the GIM does not use TimeZones from CFG layer, but it uses internal TimeZone definition which is stored within GIM database - try to check there, if all is configured properly.

[hsujdik]

You usually have to have the latest java version. GIM uses the Java tzdate from IANA database to know when the DST changes. Then, it creates the entries on DATE_TIME table accordingly with the timezone set on GIM options during the Job_MaintainGIM

[PFCCWA]

Using Java 1.7
also the time stamp in info mart log is 1 hour behind as well - same issue and resolution?

think I have to change gim date-time-tz value, then truncate calendar table (presuming date_time) then run JobMaintain.

thanks.

[PFCCWA]

hello

we are still having issues here and cannot reach a resolution with GTS.

issues at the moment:
[list]
[li]Infomart log timestamps are showing as 1 hour behind[/li]
[li]call_time from calling list is showing as 1 hour behind[/li]
[/list]

GTS initially advised we need to truncate date_time table then run jobmaintain process - but this did not resolve.  info mart GMT option values also changed to relevant java time ie Europe/Paris.
now they are advising we need to create a custom calendar to take into account time changes because we are using third party software for end user reporting.
however I am not sure this is going to resolve the issues listed.
anyone experienced same problem?

thanks.

[Kubig]

Never encountered this issue, but we always created own date_time table with properly and wanted time_zone.

[Tambo]

yes, we had same issue and it is working as designed.

GIM is in UTC and then a conversion is done to make the time correct as far as OCS, URS etc are concerned. I have pasted Genesys response below................

When OCS stores dial_sched_time/ call_time fields, it stores these in UTC. OCS uses the time zone objects in CME to convert from the time zone of the record to UTC time. When you view these fields in OCM/ GA, they should be shown in the time zone local to the record.

Note: OCS is running in BST, 1 hour ahead of GMT

When OCS received the AddRecord request:


received from 65208(sip_server_1_dc1_p)gen_obd_srv2_ipcc_sit_dc1:7017(fd=14) message EventUserEvent
    AttributeReferenceID    7
    AttributeUserData    [422] 00 10 00 00..
        ...
        'GSW_TZ_NAME'    'GMT'
        ...
        'GSW_DATE_TIME'    '04/01/2015 14:06Z'
        ...
    AttributeThisDN    '10003'
    AttributeUserEvent    EventUserEvent
    AttributeTimeinSecs    1427897188 (15:06:28)
    AttributeTimeinuSecs    426672
    AttributeEventSequenceNumber    00000000000103bb
15:06:28.426 Trc 50002 TEvent: EventUserEvent


It converted the value of the dial_sched_time to local to OCS, taking into consideration the TZOffset of the time zone of the record:


SetRecordStatus(): status Ready set for record ChainID=0, ChainN=0, RecordHandle=321
    RecordHandle = 321  ChainID = 0 ChainNum = 0
    Phone = 850441628767321
    PhoneType = 1
    ListName = FREEDIAL_UKCOLL_CallingList  TableName = FREEDIAL_UKCOLL_tbl
    CampaignName = FREEDIAL_COLLECTIONS
    Attempt = 0
    RecordType = 5
    TZDBID = 101  TZOffset = 3600 <--------------
    DailyFrom = 25200 (07:00:00)  DailyTill = 82800 (23:00:00)
    DialSchedTime = 1427893560 <------------------



And then inserts this value in the calling list:

15:06:28.430 CM_DBCallList(206-195-248): DoInsert
15:06:28.430 CM_DBCallList(206-195-248): DBServer 'ocs_dbserver_1_dc1_p for FREEDIAL_UKCOLL_CallingList (18)' SQL: insert into FREEDIAL_UKCOLL_tbl (call_result,agent_id,contact_info,contact_info_type,dial_sched_time,daily_from,daily_till,record_type,record_status,tz_dbid,attempt,campaign_id,switch_id,REMARK,FORENAME,SURNAME,chain_id,chain_n,record_id) values (28,'63003','850441628767321',1,1427893560,25200,82800,5,1,101,0,195,101,'test','Shubham','Singhania',472,0,473) [ReqID=407555]


However, if you convert "1427893560" using a epoch converter (http://www.epochconverter.com/), the value is Wed, 01 Apr 2015 13:06:00 GMT, which is 1 hour earlier than the date specified by the agent.

As the dial_sched_time has been reached, the record is retrieved and sent to an agent for dialing.

When the agent processes the record, the call_time is set to 1427897203.

UpdateRecord Handle:322 ChainID:472 ChainNum:0
15:08:15.195 CM_DBCallRecord(206-195-248): DBServer 'ocs_dbserver_1_dc1_p for FREEDIAL_UKCOLL_CallingList (18)' SQL:  update FREEDIAL_UKCOLL_tbl set call_result=33,agent_id='63003',call_time=1427897203,dial_sched_time=1427893560,record_type=5,record_status=3,attempt=1,switch_id=101  where chain_id=472 and chain_n=0 [ReqID=407708]


Again, if I convert that I get:

Wed, 01 Apr 2015 14:06:43 GMT


When viewed in GA (or OCM), the definition of the GMT time zone object is taken into account and a coversion is done to add 1 hour to each of the times displayed (dial_sched_time and call_time).

As I mentioned above, I can reproduce the issue in my lab, when I set the system time zone to GMT/ London time, and add a record with time zone = GMT. It does not happen when I disable DST Enabled on the GMT time zone object in CME (which requires an OCS restart). I also created a separate time zone object for British Summer Time with DST enabled.

[PFCCWA]

so are you saying disabling DST on the GMT time object in CME resolved the issue? and what part does a BST CME time object play in this?
if so will this also affect other components ie CCA (Datasourcer/Datamart)?

suppose this is just about how we interpret the UTC time however still thought this is a functionality which would not require any workarounds.
cannot recall doing this for cca.

thanks,

[cavagnaro]

ok, I have fight also agains DST, the issue is that you define the DST manually on the TZ field, so, have you verified it is well set? My issue here on Brazil is that DST is not fixed, every year varies or can...so we have to adjust it.
Also, no need no restart OCS...just unload the campaign and load again. Imagine what a pain in the ass would be on a PRD environment where you have multiple DST zones.

In resume, yes, Genesys works all as UTC in their DB, then OCS for example does the math of adding/substracting hours dynamically as indicated by the TZ used on that specific record.

GIM and other also report in GMT so, you need to adjust whatever extracts/collects info for that process, in this case Java engine.

PFCCWA can you post screenshot of your DST/GMT TZ settings?
You need to understand how this flow works exactly to understand your issue

On CCA you only had this issue when DST time ends as it uses own server time settings, so if windows didn't change the hour you had at the end of the last DST day an hour of 120 minutes, nothing showed that, but you noticed because the login time of an agent was like that for example.

Again, no way to compare the solutions as they work totally different at the ETL level

[Tambo]

no the Genesys fix it did not work for us, so we have had to ask if it is going to be put forward as a future enhancement.

the reporting outputs are fine, the problem is when we need to look at the raw data we have to keep this in mind