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.
Written · Updated
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
Why is the date order such a big deal?
Because it 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, and nothing in the string says which. Read a month-first file as day-first and every event moves by up to eleven months: every pattern is wrong, every window around a moment contains the wrong calls, and nothing on the page looks broken. The dates parse, the tables render, the totals add up. The only way to find out is for somebody to notice a call that could not have happened.
What does it actually mean when two numbers appear on the same cell?
That two numbers appear against the same cell reference inside the window you set. That is all. A cell serves an area (hundreds of metres in a city, several miles in open country), cells are chosen for signal and load rather than proximity, and the schedule records the cell serving the call rather than where the handset was. Two handsets on the same cell can be a mile apart on opposite sides of a river. It is a place to look, never a conclusion.
Why normalise the telephone numbers before counting anything?
Because 07700 900123, +447700900123, 447700900123 and 00447700900123 are four strings and one number, and the same export often contains more than one form. Counted as four contacts, the number you opened the file to find (the one appearing far more often than any other) is split into four unremarkable ones and never reaches the top of the list. That is not tidiness; it is the difference between seeing the pattern and not.
Can it tell me who a number belongs to?
No, and it never will. Attributing a telephone number to a person rests on subscriber checks, handset examination, admissions and other evidence, and it is where cases are won and lost. A schedule shows that a number did things. Whose hand was on the handset is a different question, and any tool that answers it is guessing.
What happens if the file is genuinely ambiguous about dates?
It says so rather than picking one and sounding certain. If every event in the column falls in the first twelve days of its month, nothing in the file settles the order, and the honest answer is to ask whoever produced it. Guessing there is not a default, it is a coin toss with the answer.
Related tools
- Speed from skid marks, as a rangeThe equations are undisputed; the measurements are not. Why a drag factor and a skid length entered as ranges give a band several miles an hour wide, and which equation is confidently wrong most often.
- Association charts, and the brokerThe person with forty connections is a switchboard. The one worth finding has three and sits on the only path between two groups, looking unimportant.
- How the PACE detention clock worksSection 41(2) gives four answers for when the clock starts, and every limit and review moves with it.
- How to analyse phone call records and find the patternsFive questions, each one pivot: who, since when and until when, what hours, where the silences are, and who two people both talk to.
- How to build a chronology when some dates are only approximateMarch 2026 is not 1 March 2026. Five kinds of date, the rule that orders them without inventing a day, how a gap is measured so a vague date cannot manufacture one, and a six-event run worked through.
A letter, now and then
An occasional letter when there is something worth reading: the new guides and what changed in the tools. Never more than once a month and nothing else, and you can leave at any time on the unsubscribe page.