Call lengths longer than 99 minutes are incorrectly reprisented

[GoogleCodeExporter]

What steps will reproduce the problem?
1. output records whose elapsedtime is greater than (I think) 99 minutes

What is the expected output? What do you see instead?

For example, for one call the elapsedtime is reported as 1:06:16.0 (one
hour, six minutes, and 16 seconds).  This would be a total of 3976 seconds.
 However, the actual length of the call was 6376 seconds.  This should have
been printed as 106:16.0, which is 6376 seconds.

I discovered this when I was seeing many long calls were exactly 2400
seconds shorter in my records than in those of my upstream provider (40
minutes).  So I tested the same records using bafview and discovered the
difference in representation.

I see the same thing in normal and CVS output, so I assume it is doing this
with database entry as well (probably to conform to ISO8601).

What version of the product are you using? On what operating system?

SVN as of 2010-01-04

Original issue reported on code.google.com by th...@bendtel.net on 8 Jan 2010 at 1:36

[GoogleCodeExporter]

hmm, I looked into the time field and I guess I was under the assumption that 
the baf
files do the /60 conversion themselves.  Ill add that in.

Original comment by charless...@gmail.com on 8 Jan 2010 at 5:44

• Changed state: Accepted
• Added labels: OpSys-All, Usability

[GoogleCodeExporter]

I should really have said greater than or equal to 100 minutes.

Original comment by th...@bendtel.net on 8 Jan 2010 at 5:51

[GoogleCodeExporter]

You mentioned you ran this through bafview as well?  
Did bafview report the corrent time or no?

Looking at the code I have for bafview it appears like we do the same thing, so 
I am
wondering if you saw something different in bafview.

Original comment by charless...@gmail.com on 10 Jan 2010 at 11:49

[GoogleCodeExporter]

Yes, I ran the same BAF file through bafview.

Where bafprp reports 1:06:16.0, bafview reports 106:16.0.  The difference in 
seconds
was part of my first entry.

The CDRs from my upstream providers show the same discrepancy that bafview 
suggests.

Original comment by th...@bendtel.net on 11 Jan 2010 at 12:02

[GoogleCodeExporter]

This issue was closed by revision r193.

Original comment by charless...@gmail.com on 12 Jan 2010 at 5:45

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok well the duration field type in bafprp was written thinking that some of the
characters were hours.  After looking at bafview and the baf files it turns out 
this
is not the case.
Very good catch, I actually remember some trouble i was having with duration 
when I
was setting bafprp up myself but I must not have thought to much about it.  

I tested the new code with bafview and bafprp to confirm that it does now 
produce the
correct duration.

Original comment by charless...@gmail.com on 12 Jan 2010 at 5:48