The jtel System takes timestamps, when a particular event happens, down to the microsecond level of accuracy, if available.
This can result in some paradoxes, when the values are used in reporting.
- Note, because of the real-time nature of the system particularly when dealing with calls, it is necessary to have timestamps of a high accuracy, to ensure that events are ordered correctly in the same order as they actually happened.
- This is particularly important for systems which need to be certified for billing purposes.
Consider the following example, which could, for example, be the times an agent spent in a particular agent status during a day.
- The actual values stored in the raw data are the times in microseconds.
- The time in seconds is used to display a hours:minutes:seconds value in a report
- This is calculated when the report is generated by rounding the microseconds value divided by 1000000 (the number of microseconds in one second)
- The sums at the bottom are calculated in the report, by summing up the relevant column.
| Status | Time in Status in Microseconds | Time in Status in Seconds |
|---|---|---|
| Status 1 | 41,570,259,033 | 41570 |
| Status 2 | 162,338,287 | 162 |
| Status 3 | 68,047,410 | 68 |
| Status 4 | 258,951,950 | 259 |
| Status 5 | 314,248,890 | 314 |
| Status 6 | 44,026,154,430 | 44026 |
| SUM | 86,400,000,000 | 86399 |
As you can see, one second has gone missing, although the sums are numerically correct.
So where did it go?
- This is due to a cumulative number of microseconds which is greater than half a second, being rounded off when the number of seconds is calculated for each row.
An alternative could be to get the sum of the number of seconds from the sum of the microseconds (which is correct) and display the following:
| Status | Time in Status in Microseconds | Time in Status in Seconds |
|---|---|---|
| Status 1 | 41,570,259,033 | 41570 |
| Status 2 | 162,338,287 | 162 |
| Status 3 | 68,047,410 | 68 |
| Status 4 | 258,951,950 | 259 |
| Status 5 | 314,248,890 | 314 |
| Status 6 | 44,026,154,430 | 44026 |
| SUM | 86,400,000,000 | 86400 |
However, astute readers will note that 41570 + 162 + 68 + 259 + 314 + 44026 does not in fact equal 86400.
This is called the rounding paradox.
So what to do? Unfortunately, there is no simple or nice way to deal with this.
- You either live with the missing second(s) in the totals
- Or you display incorrect values somewhere in the individual data rows, by adding the missing seconds from the total those rows
We here at jtel have decided to go with the first method.
So sometimes the sums in jtel reports may not add up exactly as you would expect.
Now, at least you know why!
We ask that you consider this circumstance before opening a service ticket. Simply put: This mathematical fact can not be changed.