Your photo and your walkthrough video disagree about when it happened. Both are right.

You are defending a deposit deduction. You produce two files from the same afternoon: a photo of the burned countertop, and the walkthrough video you shot on your way out of the unit. The photo carries a camera time of 15:30 on the 10th. The video’s own timestamp says 00:13 on the 11th.

The other side notices before you do. Why is your video dated the day after your photo?

Nothing is wrong with either file. You are reading two different clocks, and neither one is labelled.

Two formats, two conventions

A photo stores local time. The capture field inside a photo, Exif’s DateTimeOriginal, is a plain wall-clock reading: the time the phone was showing when the shutter fired. There is no time zone attached to it. That is not an oversight you can work around — it is why the 2016 revision of the standard (Exif 2.31, CIPA DC-008-2016) had to add three brand-new tags whose only job is to record the offset separately.

A video stores UTC. An MP4 or MOV keeps its creation time in a box called mvhd, counted in seconds from 1 January 1904. The specification (ISO/IEC 14496-12) is explicit about the zone, and about whose problem it is:

These times are expressed in UTC and therefore may need adjustment to local time if displayed.

So a photo and a video of the same room, minutes apart, are answering the same question in two different languages. In the Mountain time zone that is a six- or seven-hour gap on paper. Anywhere east of London it goes the other way. Nothing on the face of either file tells you which one you are holding.

What we measured

On 20 September 2026 we ran every real phone video we had through the same container reader our checker uses, and compared the time stored inside each file against the local wall-clock time the phone itself had written into the filename. Twelve videos, one household, all Samsung Android.

• Eleven of the twelve stored a usable time. One stored none at all — the field was there and empty, which is what happens when a file has been re-saved by something that did not bother to fill it in.
• Every stored time was UTC, and every one was correct. Six hours ahead of local in summer, seven in winter. It tracks daylight saving properly. The files are not lying; a reader who takes the stamp for local time is the one who is wrong, by six or seven hours.
• Nine of the twelve landed on a different calendar day from the time the phone put in the filename.
• Nine of the eleven were stamped when recording stopped, not when it started — matching to within three seconds.

That third figure needs a caveat, and we would rather give it than have you quote it at someone. Most of those clips were shot in the evening, and in the evening a six-hour push crosses midnight almost every time. It is not a general rate. What it does tell you is the shape of the risk: an inspection filmed after about five in the afternoon, Mountain time, will normally carry the next day’s date inside it. Late-afternoon and evening is when a lot of move-out walkthroughs happen.

The stopped-not-started detail is useful, not just trivia

Because the stamp is written when you lower the phone, a four-minute walkthrough is stamped four minutes after you began it. That makes the number self-checking, which is worth knowing when you are the one being questioned. Take the stored time, subtract your own offset from UTC, then subtract the video’s length. You should land on the moment you pressed record. On nine of our eleven, that came out within three seconds.

When it does not come out, that is worth a second look — not because it proves anything, but because a container time that no longer relates to the video’s own duration is a sign the file has been through something since the camera wrote it.

The half of this that is getting better

Since Exif 2.31 a phone can write down which zone its wall clock was in, and newer phones do. The Samsung original on our desk records -07:00 in its own file, sitting right next to the capture time, saying plainly that 15:30 meant 15:30 in Mountain Standard Time.

Until this week our checker read that tag and threw it away. It printed the capture time and stopped, leaving you to guess. From 20 September it shows the zone when the file records one, and when the file does not, it says so in as many words rather than letting a bare 15:30:37 imply more certainty than the file actually contains.

What to do with this before you argue a date

1. Never argue a calendar-day boundary from a video’s stamp alone. Notice periods, lease-end dates and “was this before or after they moved out” all turn on which day something happened, and that is exactly the question a UTC stamp answers misleadingly.
2. A video dated the next day is not evidence that anyone backdated anything. If the other side’s video is a day out, check the arithmetic before you make an accusation. You would want the same courtesy.
3. If the date matters, shoot a still as well. A still names the camera, records the shutter moment, and on a newer phone records its zone too. A video names nobody and gives you one number in a zone you have to work out. Two seconds of extra work at the unit settles it.
4. Write your own time zone down in the inspection note, not just the time. It costs nothing now and saves an argument later, particularly if the person reading it is an arbitrator in another state.
5. Do the check on your own phone once. Photograph something, film it for ten seconds, then drop both files on the checker and read the two times side by side. Whatever gap you see is the gap that will show up in your next dispute.

The limits, stated plainly

• Twelve videos from one household, all Samsung Android. That is a measurement, not a study. We have not tested an iPhone, and we are not going to tell you what an iPhone does until we have one in front of us.
• The “different calendar day” count above is a property of when those clips happened to be filmed. Treat it as an illustration of the mechanism, not as a statistic.
• A container time can be rewritten, or wiped, by anything that re-saves the video. One of our twelve had nothing left in the field at all.
• Exif can be edited by someone determined to edit it, and a phone whose clock is set wrong will write a confident wrong time into every file it makes. A timestamp is evidence, not proof.
• Our checker reads what is actually in a file and reports it. It gives no confidence score and it does not guess. A file with nothing left in it is not cleared and it is not condemned — it is just quiet, and we say that rather than dressing it up.

---

ImposterShield reads the evidence inside image and video files. It runs in your browser and uploads nothing. If a file has been stripped, it says so. That is the product working, not failing.