Picture a merchant who did everything right. The customer signed in on a Tuesday night, downloaded the file, and left a message saying thanks. Then the customer disputed the charge as "product not received." The merchant gathered the proof: a login record, a download log, the email thread. They submitted it feeling certain.

They lost. The evidence was true, and it was complete. It also contradicted itself on the page.

The login log said Wednesday. The email said Tuesday. The charge receipt said Tuesday. To a person reading fast, with a stack of other cases waiting, three dates for one evening look like a story that doesn't hold together. Nobody was lying. The clocks were just set to different places.

The quiet problem with every timestamp

A timestamp feels like a fact. In practice it is a fact plus a hidden assumption about where the clock was standing.

The same instant gets written differently by different systems. Server logs are commonly recorded in UTC. Your email client shows messages in whatever zone your device is set to. A screenshot of a chat app shows the time in the zone of the person who took the screenshot. A payment dashboard may display times in yet another setting. The customer, meanwhile, lives somewhere else entirely.

If you paste these side by side without a note, you have handed the reviewer a puzzle. The honest explanation takes one sentence. The reviewer won't be there to hear it.

Why a small mismatch does outsized damage

There's a well-documented idea in cognitive psychology called processing fluency: information that is easy to process feels more true, and information that causes friction feels less trustworthy. People tend to make this judgment without noticing they're making it. A clean, consistent document reads as credible. A document with small snags reads as suspect, even when each snag has an innocent cause.

A dispute reviewer is not auditing your logs. They are building a quick impression of whose account hangs together. When your access record says the 14th and your receipt says the 13th, the friction registers as doubt. And in a dispute, doubt is expected to cost you, because in a chargeback you are the one who has to carry the burden of showing the transaction was legitimate.

The tragedy is that you can remove this friction entirely, for free, before you submit.

Where the dates actually collide

There are three places this tends to go wrong.

The midnight boundary. A purchase made at 11:40 p.m. in New York is already the next calendar day in UTC. If your logs are in UTC and the customer's receipt is in local time, a single evening produces two different dates. Any evidence tied to "the day of purchase" can seem to be off by one.

Ambiguous date formats. Written as 03/04/2026, a date means March 4 to many readers in the United States and April 3 to many readers elsewhere. If your evidence mixes numeric formats from different tools, a reviewer can misread the order of events, and "before" can quietly turn into "after." Order of events is exactly what many disputes turn on: did the customer use the product before they claimed it never worked? Did they contact you before or after the dispute?

Screenshots with no zone at all. A chat screenshot often shows only "9:12 PM." Nine twelve where? Whose phone? Without an anchor, that time proves little and invites questions.

The fix is a single decision

Pick one reference and make everything obey it. For most merchants the cleanest choice is UTC, because it has no daylight saving shifts and no regional ambiguity. Then do three things.

First, state the convention once, near the top of your response, in plain language. Something like: "All times below are in UTC unless marked otherwise." One line, and the reviewer stops wondering.

Second, write dates in an unambiguous form. Spelling out the month, or using the year-first format (2026-03-04), removes the day-month guessing game entirely.

Third, when you have to include a record in a different zone, say so next to it rather than silently converting. If a screenshot shows 9:12 PM Pacific, write "9:12 PM Pacific (04:12 UTC the next day)." You are showing your work, which is what builds trust.

Don't alter the evidence, annotate it

A caution matters here. Never edit a log, rewrite a screenshot, or change the original time on a record to make things tidy. Altered evidence is worse than inconsistent evidence, and it can destroy your credibility if anyone notices. The goal is translation, not revision.

Keep the original artifact exactly as it was captured. Put your conversion in your own written summary or a short caption beside it. The reviewer can then see both the raw record and your reading of it, and the two will agree.

Check the one date that matters most

Of every date in your file, one deserves a second look: the date the customer received or used what they paid for. That is usually the hinge of the dispute. If the customer's own dispute claims they never got the product, the timestamp on your delivery, access, or download record is the quiet center of your whole case.

Before submitting, confirm that this date reads identically in your summary, your logs, and any message thread you attach. If the zone conversion pushes it across a day boundary, call that out directly instead of leaving it for the reviewer to discover.

Your next moves

  • Choose your convention today. Decide that all dispute evidence will be presented in UTC, and write the one-line statement you'll paste at the top of every response.
  • Rewrite your key dates in an unambiguous format. In your next response, use "4 March 2026" or "2026-03-04" instead of numeric dates like 03/04/2026.
  • Annotate, don't edit, every screenshot. Add a caption under each one with the original displayed time, the zone it was captured in, and the UTC equivalent. Leave the image itself untouched.
  • Find your midnight-boundary risks. Look at your last few orders and flag any purchase made within a few hours of midnight in your customer's zone or yours, since those are the ones most likely to show two different dates.
  • Run a one-minute consistency check before you submit. Read only the dates in your file, top to bottom. If any single event shows up on two different days, fix the explanation, not the evidence.

A last note on small things

Most lost disputes feel like they were lost on the big questions: did the customer get the product, did they agree to the terms. But a surprising number slip away on the small ones, where the proof was there and the presentation made it look shaky.

This is the kind of detail Argeback is built to handle for you. When it drafts a response, it assembles your records into one consistent account, so the dates agree with each other before anyone reads them, and it files before the seven-day deadline, even if you're doing it from your phone. If you'd rather not be the person proofreading clocks at 11 p.m., you can see how it works at argeback.lumenlabs.works.