Every Tool Has Its Own Midnight

Somebody says the number was 412. Somebody else says it was 389. Both of them pulled it this morning, out of systems that are working exactly as designed, and neither of them is wrong.

Everyone in the room treats this as a data quality problem. It usually is not. It is a calendar problem. Your tools do not agree on when Tuesday ends.

The dumbest possible reason your numbers do not match

Your analytics property carries a reporting time zone that somebody picked during setup, once, in a hurry, probably matching whatever city that person was sitting in at the time. Your payment processor reports in UTC unless someone went and changed it. Your CRM stamps records against a portal-level setting, and then some of its reports bend to the individual user’s locale on top of that. Ad accounts get a time zone assigned when the account is created, and on more than one platform that choice is effectively permanent without a support ticket.

So you are running four or five systems, each with its own midnight, each set years ago by a different person, most of whom no longer work there. Nobody made a decision about this. A decision simply happened to you.

And the gap is small. That is the entire problem. If the discrepancy were forty percent, somebody would have fixed it in 2019. At two or three percent it just sits there, low grade and permanent, and every report in the company is quietly roughly right.

Then it gets worse, because nobody agrees what “last 30 days” means

Time zone is only the first layer. Underneath it is the range itself, and the range is a free-for-all.

• Does “last 30 days” include today, a day that is not finished and never compares fairly to anything?
• Is “last week” a rolling seven days or the calendar week, and does that calendar week start Sunday or Monday? Tools default differently, and almost nobody checks.
• On the first of the month, does “last month” mean the month that just closed, or the one that is one day old?
• Does your quarter follow the calendar, or the fiscal year that finance uses and marketing has never once opened?

Every one of those is a defensible choice. That is exactly why you have all of them running at the same time, in different tools, reporting to the same meeting.

And then the layer nobody catches: which date

Pick any record in your CRM and count the timestamps hanging off it. Created. First touch. Last activity. Last modified. Stage changed. Closed. That is six different Tuesdays for one object, and a report has to choose one.

A deal created in August and closed in September sits in August in one report and September in another. Same rows, same database, two different months, both correct. Worse: somebody re-runs the same saved report a quarter later and the number has moved, because it was bucketing on last modified and records kept getting touched. Nobody wrote down which field that report used. So nobody can explain the change, and the blame lands on the tool, or the integration, or the new person.

Why this never gets fixed

Because it is boring, and because it belongs to everyone, which means it belongs to no one. There is no owner of the definition of a day. Fixing it is a settings page in five products, a conversation with finance about fiscal calendars, and a document that somebody has to maintain. Nobody has ever been promoted for that.

It is also small enough to shrug at, right up to the moment it is not. Think about where a boundary error does the most damage. The boundary. The last day of the quarter, when deals close at six in the evening and land on one side of the line in one system and the other side in another, and two teams spend a week arguing about whether the quarter was made while both of them are holding true numbers.

The cost is not the number. The cost is that once two numbers disagree and nobody can say why, every number in the company becomes a matter of opinion.

That is the real damage. Not a rounding error. A slow drain on whether anyone believes the reporting at all.

What actually fixes it, and it is embarrassingly unglamorous

Pick one clock and write it down. One sentence: all company reporting is in this time zone. Then go set it in every system that lets you, and make a list of the ones that will not, because those are the ones that need an offset applied forever and a note explaining why.

Pick one date field per object and say it out loud. Pipeline is bucketed on created date. Revenue is bucketed on the date the money actually moved. Traffic is bucketed on session start. Publish the list somewhere a new hire will find it in week one instead of month nine.

Make every report state its own boundary. A number with no definition attached is a rumor with a decimal point. Put the window, the clock, and the date field in the header of the thing. It takes ten seconds and it ends about half of the arguments before they start.

Reconcile once, deliberately. Pick a single boring week from two months ago, long settled, nothing in flight. Pull it from every system that reports on it. Line the numbers up in one view. Whatever you cannot explain in that comparison is not a curiosity, it is your actual backlog, and it has been silently taxing every decision you have made this year.

None of this is sophisticated. It is the data equivalent of labeling the leftovers in the fridge. It is also the difference between a reporting stack people argue with and one people argue about.

The tell

You know you have this problem if there is a spreadsheet somewhere on your team with a cell in it whose only job is to make two numbers match. An adjustment. A fudge. A plug. Nobody remembers who wrote the formula, everybody updates it monthly, and it has been load-bearing for two years.

That cell is not a hack. It is a fossil record of a definition nobody ever agreed on, and it is doing the work that a decision should have done.

Worth saying plainly: none of the above is a software problem. No tool decides your fiscal calendar or which timestamp counts as the truth for a deal. Those are decisions, and they stay yours.

What software can take off your plate is the part right after the decision. The answer lives in five places, somebody has to go collect it by hand every time, and that hand-collection is an afternoon somebody loses every week. That is the part we work on at I Hate Marketing: putting the whole stack in one place so a question gets asked once instead of re-assembled from five exports by whoever is free that afternoon. Make the calendar decision first, and write it down, so you are not re-litigating it every quarter.