ECHI Records with two hours drift for segstart and segstop

[gvag]

Hi all,

In a previous post, i wrote about a problem with the segstart and
segstop beeing 2 hours ahead than the actual time the call took
place.So i make a test call at 14:30 and i can see in the database
that the segstart of the call is 16:30.

I had on the phone an Avaya CMS Specialist who helped me a lot with
some tests. Actually we converted the binary ECH file to ASCII file
containing all the details of the records. In this ASCII file the
segstart and segstop fileds contains the date/time is unix-long-time
format and then i used the /cms/toolsbin/showtime xxxxxxxxxxx command
to convert it to actual date/time. The result was that the ECH record
on the CMS side was correct.

The problem seems to occur when the ECHI-Converter process the ECH
files.

I was wondering if there is a setting i need to check on the ECHI-
Converter project .

Also, any idea on how does Ruby.Time class converts the unix-long-time
to actuall date, any possibility that there is a problem there?

Regards
George

[gvag]

Also I figured out the following :

The epoch time i get for the ECH file is 1231512138 which if i convert
it to date/time it is like this:

GMT: Fri, 09 Jan 2009 14:42:18 GMT
EET: Fri 09 Jan 2009 04:42:18 PM EET

The correct date/time(the time that the call was made) is the one for
the GMT, but i am located at the EET timezone.

So the Time.at() method assumes that the epoch it gets is at GMT and
trying to convert it to the current timezone add 2 hours which is
wrong indeed.

Off course a workaround could be to change the timezone of the ECHI-
Converter server to GMT but this is a workaround. Does somebody have
any idea to fix this to the ECHI_Converter?

Regards
George

[JasonGoecke]

Good timing as I just extracted the methods that perform the
conversion into a stand alone library here:

http://jsgoecke.github.com/echi_files/

If you post one of the files that you know what time it is suppose to
be, and that it is in EET, I may then have a look at what I get on my
side. You may see how the conversion is being done here in line 26 -
31:

http://github.com/jsgoecke/echi_files/tree/master/lib/echi_files.rb

[gvag]

Jason,

Check the chr1101 file. Among others you will find one record where
the callingparty = 6932363163 . This record refers to a call that took
place at 14:42:18.

Thanks
George

[JasonGoecke]

Here is what I am seeing:

http://gist.github.com/45115

When you say 14:42:18, which timezone are you referring to?

[gvag]

Jason,

Forgot to mention it. I refer to EET (GMT+2) . Also both CMS server
and ECHI-Converter server are set to EET timezone.

As i said earlier, if i changer the timzone of the ECHI-Converter
server to GMT i can see the segstart and segstop correct.

I am quite confused where the problem is....

[JasonGoecke]

Incidentally, I am in PST in the San Francisco Bay Area.

[gvag]

I beleive that the ECHI app runing on CMS creates the records using
the GMT , ignoring the TZ setup of the Solaris box.

But then again if i use the /cms/toolsbin/showtime 1231512138 , i will
have the the date time correct.... ;o)

On Jan 9, 4:33 pm, JasonGoecke <jsgoe...@gmail.com> wrote:

[JasonGoecke]

Okay, so if I take the time (http://en.wikipedia.org/wiki/Unix_time)
and manipulate it locally in irb (I am running on OSX) I get this:

http://gist.github.com/45119

This is correct behavior, as we see the offset and the correct GMT
time which is 14:34:39 for that record (first record calling party
001A03019). Now, I if I am following, what you are saying is making it
into your database is GMT as if it were your local offset. So for some
reason the offset is not taking into account on Solaris?

Please confirm I am following correctly here, as of course this gets
confusing fast.

[gvag]

Yes you are right. Seems that the ECHI application (running on
Solaris) is not taking into account the timezone. I beleive that the
records i get, are in GMT.

I did the same tests like you with irb and Time.at() and i have the
wrong time.

One workaround could be as i said, to change the ECHI-Conv. server to
GMT. I test it and its fine like this.

But i am wondering how come i am the only one having this issue?

Do you have any idea on how this could be changed without changing to
GMT the server?

Regards

[gvag]

One more thing, using the /cms/toolsbin/showtime 1231512138 , then i
get the correct time.

What about this?

[gvag]

Another workaround could be to change the source code to value =
Time.at(value).getgm , but i don't like, its not a "clean" solution.

[JasonGoecke]

I may download OpenSolaris (http://opensolaris.org/os/) and give it a
shot (probably sometime next week), although since it will be running
on Intel in VMWare it may not reproduce the problem. If you could give
me temporary SSH access, or we could do something like a DimDim/
GoToMeeting session I could have a play on the irb there and see if I
may figure out something elegant that applies cross the board.

As I am not seeing this issue on OSX or Linux.

[gvag]

I can provide you with ssh access on the Solaris, on Mondya though.
Bare in mind that on the Solaris it is just the CMS that is running
and with the uucp script (using ftp) i move the files to the ECHI-
Converter server (which is a virtual machine currently). I will let
you know the details on Monday (i will send you an email).


Thanks.

[JasonGoecke]

Ah, ok, I thought you referring to the ability of determining the time
offset on the Solaris/CMS server because ECH-Converter was running
there. If ECHI-Converter is running on another machine what counts is
that you have that timezone set correctly and may get the appropriate
off set.

So, in order to have some background:

1. Which OS is that Virtual Machine running ECHI-Converter?
2. What timezone is it set for?
3. May you see the appropriate offset?

What appears to be correct is the data coming from CMS with the
seconds from January 1, 1970 GMT, as I may properly see offsets and
the right time as indicated above. What counts in this configuration
is where the ECHI-Converter is running and therefore thinks its
timezone is.

[gvag]

Jason,

Here are the answers:

1. The Echi-Converter is running on Debian
2. The timezone the virtual machine is running is EET (GMT+2)
3.I don't really understand this question.

When i change the timezone from EET (GMT+2) to GMT on this machine,
then i can see the records with correct segstart and segstop.


Thanks

[JasonGoecke]

Since no one else is reporting this issue, I have not observed
elsewhere nor been able to re-create, I will consider it something
obscure to your setup. Let us know if you come up with anything.

Good luck!

[mattfitzwater]

I am having a problem with the time conversion on the echi files. I
have an install on the East Coast that is 5 hours off and an install
on the West Coast with 8 hours off. This is consistant with gmt
exactly. Eastern is gmt -5 and Pacific is gmt -8. Can there be a
entry added in the service config to compensate for gmt time
difference?

[JasonGoecke]

If you look at line 51 in this library (which is really just pulled
straight out of the current 0.4.1 version):

http://github.com/jsgoecke/echi_files/blob/c423d132b5e6ccdaea6930d49f1175ca21de1834/lib/echi_files.rb

You will see that it simply takes the value passed in the file by CMS/
ECHI and applies time object at that time value. If you look at the
method 'at' of the Time class you see it is starightfoward and should
be picking up the timezone from the local machine:

http://www.ruby-doc.org/core/classes/Time.html#M000250

If you could post a file that you know what time it 'should be' versus
what time ECHI-Converter is purporting, we may see what we may track
down on this one. Now that we have a second incidence being reported,
this is obviously quite important.

[JasonGoecke]

This enhancement could be a solution for you:

http://groups.google.com/group/echi-converter/t/29780dd4925b61ae