Images & photos · Image Metadata Privacy Tool
EXIF Dates Have No Time Zone: DateTimeOriginal, OffsetTime and GPS Time
· Background
exif image-privacy file-formats
EXIF records capture time as a plain local clock reading with no zone, and only since 2016 has it had optional offset tags, while the GPS block records UTC. This post explains the three date fields, the offsets, and how the mismatch can reveal where you were.
Photos out of order after a flight — the practical symptom of timestamps with no time zone
Photographs can sort unexpectedly after travel because several clocks may describe different events and may not include enough context to compare them safely. ToolAcre exposes the timestamp fields it recognises, but it does not repair their values or infer a time zone. Read them as claims written into the file, not as an authenticated itinerary.
Three date tags, three meanings — DateTime (last modified), DateTimeOriginal (shutter) and DateTimeDigitized (scan or capture), all in 'YYYY:MM:DD HH:MM:SS' form
DateTime records when the file was last written, DateTimeOriginal describes when the photo was taken and DateTimeDigitized describes digitisation. An editor can update one while leaving another intact. The tag dictionary keeps those meanings distinct so a user looking for capture time does not mistake a later file-write time for the shutter event.
Sub-second capture time is readable; offset tags are not
SubSecTimeOriginal is recognised and can refine the capture clock. The workbook said this tool reads optional offset tags, but the shipped tag table contains no OffsetTime fields, so this section corrects that implication. An offset may exist in a broader EXIF model without appearing in this bounded report; absence from the table is not proof of absence from the block.
GPS supplies separate time and date fields
The GPS directory recognises GPSTimeStamp and GPSDateStamp as location-sensitive fields. The repository does not contain the external standard text needed to claim their universal UTC semantics here, so the article reports the separate fields without turning them into a guaranteed zone conversion. They remain sensitive because they record when the location data says the photograph was made.
What timestamp differences may suggest, but cannot prove
Differences among capture, write and GPS fields may suggest editing, clock configuration or travel, but metadata can be stale or deliberately changed. The viewer does not decide which explanation is correct. Correlate with a known workflow if accuracy matters, and avoid publishing timestamps merely because they seem harmless beside coordinates.
Worked example: reading one photo's dates — laying the tags side by side and working out what a stranger could infer
Inspect one photograph and compare DateTime, DateTimeOriginal, DateTimeDigitized, SubSecTimeOriginal, GPSTimeStamp and GPSDateStamp when present. Note which directory supplied each value. If sharing does not require chronology, remove the whole block; selective timestamp retention is unavailable because cleaning operates on container blocks rather than individual tags.
What this does not cover — correcting timestamps or shifting them in bulk, which is an editing job
This tool does not correct camera clocks, assign zones, merge sidecar catalogues or recover fields outside its dictionary. It also cannot inspect unsupported RAW or HEIC sources. XMP may carry additional history without being displayed, and visible scene clues can still reveal time or place after all supported metadata leaves.
Takeaway: timestamps are location data too — the Image Metadata Privacy Tool shows all of these fields and strips them together
Treat timestamps as privacy-relevant context even when they are not coordinates. Inspect all recognised clocks together, preserve the authoritative master privately and create a cleaned derivative for publishing. The useful discipline is distinguishing field meanings and parser limits, not forcing incomplete metadata into a precise travel timeline.