Reading a schedule of call data, and the two mistakes that do the most damage
A schedule of call data is a spreadsheet full of people who have nothing to do with your matter. Two errors account for most of the harm done with one: reading the dates in the wrong order, and reading a cell site as a location. Neither looks like an error on the page.
A schedule of call data lists who contacted whom, when, for how long, and which cell served the call. COMMS reads one in the tab: you match the columns up, it normalises the numbers, settles the date order before reading a single row, and shows the patterns. Thousands of other people's telephone numbers never leave your machine.
The date trap
This is the error that does the most damage and shows the least.
03/02/2026 is the third of February or the second of March depending on who exported the file. There is nothing in the string that says which, and a schedule can run for months without containing a single unambiguous date if every event happens to fall in the first twelve days of a month.
Read a month-first file as day-first and every event moves by up to eleven months. Every pattern is wrong. Every window you draw around a moment contains the wrong calls. The daily and hourly breakdowns are wrong. And nothing on the page looks broken — the dates all parse, the table renders, the totals add up. You get a confident, well-formatted, completely false picture, and the only way to find out is for somebody to notice a call that could not have happened.
The right handling is to settle the question for the whole file before reading any row of it. Scan the entire column first: a single value with a first component above twelve settles the order for the file, because no file mixes the two conventions. If the whole column is ambiguous — every event in the first twelve days of its month — then the file genuinely does not say, and the honest thing is to ask rather than to guess. Guessing here is not a default, it is a coin toss with the answer.
The cell site trap
The finding people over-read is two numbers appearing against the same cell reference within some window of each other. It is easy to write that up as "the two handsets were in the same place at the same time". It does not mean that.
- A cell serves an area, not a point. Hundreds of metres across in a dense city; several miles in open country. Two handsets on the same cell can be a mile apart and on opposite sides of a river.
- Cells are chosen for signal and load, not for proximity. A handset does not always use the nearest mast. It uses the one the network gives it, which shifts with congestion, with weather, with which way somebody is facing.
- The schedule records the cell serving the call, not where the handset was. Those are different facts, and only one of them is in the file.
So the useful output is the pair, the cell, and the times — stated and then stopped. It is a place to look. Turning it into a conclusion requires other evidence, and a tool that presents it as a conclusion is doing you harm.
One number, one identity
A less dramatic error, but it buries findings routinely. 07700 900123, +447700900123, 447700900123 and 00447700900123 are four strings and one telephone number. Providers are inconsistent about which form they write, and the same number often appears in more than one form within a single export.
Count those as four contacts and the number you opened the file to find — the one that appears far more often than any other — is split into four unremarkable ones and never rises to the top of the list. Normalising before counting is not tidiness; it is the difference between seeing the pattern and not.
What a schedule cannot tell you
It does not say who a number belongs to. Attributing a telephone number to a person is a separate exercise resting on subscriber checks, handset examination, admissions and other evidence, and it is where cases are won and lost. A schedule shows you that a number did things. Whose hand was on the handset is a different question, and any tool that answers it is guessing.
It also does not record content. A schedule of call data is who, when and for how long — not what was said.
Why this must stay on your machine
A schedule is overwhelmingly made up of people with no connection to the matter: the pizza place, the dentist, the family. Putting that through a website means handing a third party a list of thousands of people's telephone numbers and their contact patterns, in exchange for arithmetic a browser does in a couple of seconds.
There is no version of that trade that is worth making. Parsing a CSV and counting is not hard computing, and it has no business leaving the tab.
The short version
| The job | Here | Notes |
|---|---|---|
| Read any provider's export | Yes | You map the columns; headings matched where recognisable |
| Settle the date order before reading rows | Yes | Whole column scanned first, and the finding is stated |
| Say so when the file is genuinely ambiguous | Yes | Rather than picking one and sounding certain |
| Normalise numbers before counting | Yes | Four strings, one number |
| Quoted fields, both line endings, a BOM | Yes | Real exports are untidy |
| Tens of thousands of rows | Yes | Parsed in the tab in seconds |
| Work with no connection | Yes | The file never leaves the machine |
| Place a handset | No | A cell serves an area; the schedule records the cell |
| Say who a number belongs to | No | Attribution is a separate exercise on other evidence |
| Show content | No | A schedule is who, when and how long |
Questions people ask about reading a schedule of call data