Photographs, Timestamps and Time Zones
Photographs carry times that look authoritative and are generated by a clock somebody could have set to anything. Time zone handling then adds a second layer of confusion, and the result is that two pictures of the same moment routinely disagree.
The rule in short
A photograph's recorded time comes from the device's clock, expressed in the zone the device was set to, and stored differently depending on the format. Comparing images from two devices, or one device that traveled, requires establishing both clocks before any conclusion is drawn. Corroboration from a source outside the camera resolves most of these questions quickly.
A photograph appears to carry an objective record of when it was taken, and what it actually carries is a reading from a clock inside a device that anybody could have adjusted. Understanding how that reading is produced and stored is what makes photographic timing usable rather than misleading.
Where the recorded time comes from
The device's own clock. Set automatically from the network on most modern devices and manually on some, and wrong on more of them than anybody would expect after a battery has been flat.
Expressed in the device's zone. A camera set to one zone and carried into another continues recording in the zone it was set to until somebody changes it or the network does.
Stored differently by format. Some image formats record only a local time with no offset, so the same value means different instants depending on where the device thought it was.
Written once, at capture. The recorded time is fixed when the image is created, so later handling does not correct it however obviously wrong it turns out to be.
Separate from the file system time. The operating system records its own creation and modification times, which differ from the embedded capture time and change when the file is copied.
And separate again from any upload time. A platform records when it received an image, which is a third value and the only one nobody could have set.
Why two images of one event disagree
Different clocks. Two devices set independently will drift apart, and a difference of several minutes between phones at the same event is entirely ordinary.
Different zones. A traveller's device set to a home zone records local events in that zone, producing a difference of hours from a device set locally.
Automatic updates at different moments. A device that connected to a network and corrected its clock partway through an event produces images before and after the correction that are inconsistent with each other.
Daylight saving transitions. Handled differently by devices and by software reading the files, and a source of exactly one hour of confusion twice a year.
Manual adjustment. Somebody who set a clock wrongly, or deliberately, produces a consistent offset that is invisible unless a reference is available.
| Time value | Set by | Reliability |
|---|---|---|
| Embedded capture time | The device's clock | As reliable as that clock |
| File system creation time | The operating system | Changes when the file is copied |
| Platform upload time | The service | High, but later than capture |
| Time shown in a chat interface | The receiving device | Displays in the reader's zone |
Establishing the offset
Find a reference in an image. A clock, a screen, a dated newspaper or a receipt visible in a photograph fixes the real time and exposes any offset in the device's clock.
Use another source from the same device. A message sent moments before or after an image, whose transmission time is recorded by a network, ties the device's clock to a reference.
Check the settings record. Devices and accounts record time zone settings and changes to them, and that history explains offsets far more quickly than inference does.
Compare against a platform receipt. The time a service received an upload is recorded by the service, and the gap between that and the capture time constrains the possibilities.
Then apply the offset consistently. Once an offset is established, every image from that device shifts by the same amount, which usually reconciles an apparently chaotic set.
The fastest way to establish whether a device's time was right is to find an image from the same set containing a visible clock, screen or dated document. One such image fixes the offset for every other photograph the device took.
What platforms do to images
Re-encoding removes data. Most services generate a new file on upload, discarding the camera's embedded information, as what metadata records sets out.
Location is stripped deliberately. Almost every social and messaging platform removes location from uploaded images, on privacy grounds, so an image received through one carries none.
The upload time is added. Services record when they received a file, and that value is reliable in a way the camera's own timestamp is not, because no user set it.
Compression changes the image. Which matters where the content rather than the timing is in issue, because detail lost in compression cannot be recovered.
Original copies are worth finding. The version in the device's own library, or in an account backup, retains everything the shared copy discarded, which is why preserving the device matters before anybody starts forwarding pictures.
Using photographs well
Obtain originals rather than shared copies. From the device or from the account backup, because the version that traveled through a messaging application has lost most of what made it checkable.
State the source of every time. Whether a time comes from the camera, the file system or a platform receipt, because those three answer different questions with different reliability.
Do not assert precision. A photograph establishes a sequence far more reliably than it establishes a moment, and claims should be pitched accordingly.
Corroborate from outside. A message, a card transaction or a carrier record from the same period ties the images to a reference that nobody involved was in a position to adjust, as call records illustrates.
Preserve the library, not the picture. The device's photograph library carries the sequence, the gaps and the associated data, all of which disappear when single images are exported.
The central point is easily stated and constantly forgotten: a photograph's timestamp is a reading from a clock inside a device, and the person who owned that device could have set it to anything at all. Everything else in this subject follows from that.
Time zones then add a second and larger source of confusion. A device carried across a boundary keeps recording in the zone it was set to, and formats that store no offset make the resulting values impossible to interpret without knowing the setting.
Because of both, the useful discipline is to establish an offset rather than to argue about individual times. One image containing a visible reference, or one message with a network-recorded transmission time, fixes the correction for an entire set of photographs.
Platforms make all of this worse and occasionally better. They strip the camera's data, which removes the evidence, and they record their own receipt time, which is the one value in the whole exercise that no user was in a position to set.
In practice, the most valuable thing anybody can do is obtain the original library rather than the shared images. Sequence, gaps and associated data all survive there, and every one of them is lost the moment individual pictures are forwarded.
Points to carry away
- The recorded time is the device's clock, not a reference time.
- Time zone is recorded inconsistently between formats.
- Two devices at one event routinely produce different times.
- Platforms strip or rewrite the recorded time on upload.
- Corroboration from outside the camera settles most disputes.
Questions readers ask
Can a photograph's timestamp be changed?
Yes, in two different ways, and both are easy. The device's clock can be set to any value before an image is taken, which produces a photograph whose embedded time is wrong from the moment of capture. Separately, the embedded data can be edited afterward with freely available tools. Neither is difficult, which is why photographic timing is corroborated against sources outside the camera wherever it matters, rather than being relied on alone.
Why do photographs from two phones at the same event show different times?
Because they are reading two independent clocks, possibly set to two different time zones, and possibly correcting themselves from the network at different moments. Differences of several minutes are entirely ordinary; differences of exactly one hour usually indicate a daylight saving handling issue; differences of several hours usually mean one device was set to another zone. None of those is evidence of anything, and all of them are resolved by establishing each device's offset against a common reference.
Is the time shown in a messaging app reliable?
It is displaying a time, usually converted into the reader's own time zone, from data the application holds. That is quite different from the time a photograph was taken, which may be days or years earlier. Where the question is when an image was sent, the transmission record held by the platform is the reliable source; where the question is when it was taken, the interface display says nothing at all about that and the original file has to be obtained.
Sources
- Federal Rules of Evidence — Rule 901, Authenticating or Identifying Evidencelaw.cornell.edu
- Federal Rules of Evidence — Rule 1001, Definitions That Apply to This Articlelaw.cornell.edu
- Federal Rules of Evidence — Rule 1002, Requirement of the Originallaw.cornell.edu
- Federal Rules of Civil Procedure — Rule 34, Producing Documents and Electronically Stored Informationlaw.cornell.edu
- National Institute of Standards and Technology — Publicationsnist.gov
- Legal Information Institute — Authenticationlaw.cornell.edu
True Justice Record is a publication, not a law firm. This article states general rules and cites its sources; it is not advice about any particular case, and the law differs by state and changes over time.
More in Evidence That Lives on a Phone
When a Device Is Lost or Wiped
Where a device is gone, provider-held account data is unaffected, backups may capture an earlier state, and the other participants in any conversation hold their own copies. The circumstances of the loss then matter separately: an ordinary loss is neutral, while a wipe performed after a duty to preserve arose is treated as spoliation.
Voice Notes and Recordings
A recording is authenticated by evidence of how it was made and by whom, identification of the voices on it, and confirmation that it is complete and unaltered. Transcripts are aids rather than evidence. Editing is easy and increasingly hard to detect, so provenance carries more weight than any examination of the audio itself.
Location History Offered as Evidence
Location evidence comes from satellite positioning, from network cell sites, from wireless network observations and from application check-ins, each with a different accuracy. All of it places a device rather than a person. Interpreting it responsibly means establishing which method produced each point and what margin that method carries.