You need to know when a clip was filmed. The file explorer says one date, the video player says another, and an online viewer says a third — three hours off the first two.
None of them are lying. They are reporting different fields that mean different things, and telling them apart takes about a minute once you know what you are looking at.
How to find when a video was recorded, in order of reliability
Start with the container, not the filesystem. The dates written inside the file are the ones closest to the recording, and everything else describes a copy.
Open the clip in our video metadata viewer and you will see each date listed separately with a note on what it means. Usually there are two or three. Occasionally there are four.
The one you want is the encoded date, written by whatever created the file. On a phone or camera, that is the moment recording stopped. On an export from an editor, it is the moment the export finished — which is a genuinely different thing and the reason exported clips confuse people.
Media Created versus Date Modified, and why they disagree
Windows blends two different sources in the same panel, which is where a lot of the confusion starts.
Media Created under the Origin heading comes from inside the file. It is container metadata and it travels with the video wherever it goes.
Date Created and Date Modified come from the filesystem. They describe when this copy landed on this disk. Download a two-year-old video today and its Date Created is today, which is accurate and useless.
macOS behaves similarly, showing a Finder date that reflects the copy. The rule that survives both: if a date changes when you move the file, it is not about the recording.
Why the timestamp looks hours out
This is the single most common reason people conclude a file has been tampered with, and it is almost always innocent.
The MP4 specification stores creation time in UTC. A clip filmed at ten in the morning in London during summer therefore carries 09:00, and a tool reporting the stored value faithfully shows 09:00.
Apple devices add a second field, com.apple.quicktime.creationdate, that carries a real timezone offset — the same clip reads 2026-06-14T10:22:11+0100. Both values are correct and they describe the same instant. Software that picks one at random, or converts one and not the other, produces the mismatch people notice.
We list them separately for exactly that reason. A gap matching your timezone offset is a conversion, not a discrepancy. A gap of days is a different matter and usually means the device clock was never set.
The QuickTime creationdate on iPhone footage, in detail
Apple's field is the most useful timestamp in consumer video and the least known.
Because it carries an offset, it tells you the local time where the recording happened rather than where you are reading it. Holiday footage filmed in Tokyo keeps its Tokyo time, which is what you actually want when reconstructing a day.
Two caveats. The field only survives while the file stays a QuickTime-style container, so converting to a different format often drops it. And it reflects the phone's own timezone setting, so a phone that never updated after a flight records the departure timezone for the whole trip.
Android is less consistent. Some manufacturers write a similar field, many write only the UTC creation time, and the tags they use are not standardised. There is more on those container-specific entries in our explainer on video metadata.
When a video sent by WhatsApp has no date at all
Received video is the hardest case, and the honest answer is often that the date is gone.
WhatsApp, Telegram, Messenger and Instagram all re-encode video on send. The result is a new file written at the moment of forwarding, carrying the forwarding time if it carries anything. The original date was not hidden or stripped maliciously; it was never copied into the new container.
What you can still use is the chat timestamp, which gives you a ceiling — the video cannot have been filmed after it was sent. That is weaker than people want and it is genuinely useful in a dispute about sequence.
To get the real date, ask for the original file rather than the message. AirDrop, a cloud link, or an email attachment all pass the container through untouched. Telegram's document mode does too, which is worth knowing in both directions.
Photographs travel the same route and lose the same fields, which we tested platform by platform in what social media strips from your photos. The lesson carries over: the date survives the trip only when the file does.
Dates that are simply wrong
Sometimes the field is intact and the value is nonsense, and the reasons are mundane.
A camera that lost power resets its clock, often to the firmware build date, so files appear to come from years ago or years ahead. Action cameras and cheap dashcams do this after every flat battery. Devices with no network sync drift steadily and never correct themselves.
Dashcams deserve their own warning. Many have no timezone setting, so the on-screen stamp and the container date disagree by a fixed offset. If you are relying on dashcam footage for anything, check both and note the difference before you need it.
Using a date as evidence
Every field described here can be rewritten in seconds with free tools. That is not a reason to ignore them, and it is a reason not to lean on them alone.
Corroboration is what makes a timestamp worth something: a message that carried the file, a cloud backup with its own server-side record, another clip from the same session, a GPS timestamp from satellites rather than the device clock. Any one of those turns a claim into support.
If a clip may ever matter, keep the original untouched and work on copies — including when you remove metadata from video for a separate purpose, since stripping the dates is permanent for that file. We go through what holds up and what does not in whether video metadata can be faked. If location is the question rather than time, whether videos store GPS covers the equivalent ground.