Photo timestamps — four EXIF fields, three of them disagree
EXIF carries three independent timestamp fields plus three subsecond companions, and as of EXIF 2.31 a separate UTC offset. Most of the time they agree. When they don't — and they don't more often than people expect — knowing which one to trust is the difference between a correct photo timeline and a confidently wrong one.
DateTimeOriginal — the canonical one
Tag 0x9003. The instant the shutter fired, as recorded by the camera's internal clock. Format "YYYY:MM:DD HH:MM:SS", no timezone. This is the field every photo-management app calls "the date taken". Cameras write it on every capture; smartphones write it the moment the capture-button event fires.
The catch: the camera's clock might be wrong. People travel without changing the camera time. Daylight-saving transitions slip through. Battery pulls reset Casio-style consumer cameras to "2000:01:01 00:00:00". Any timeline you build from DateTimeOriginal alone is only as accurate as the clock that wrote it.
CreateDate — the digitisation moment
Tag 0x9004, also called DateTimeDigitized. Spec definition: when the image was converted to digital form. For a born-digital photo (any modern camera or phone), this is identical to DateTimeOriginal down to the second. For a scanned negative or slide, it's the moment the scanner produced the file — different from DateTimeOriginal (which the scan operator is expected to set to the negative's original capture date).
In practice, the two fields disagree for film-scanning workflows and for any pipeline that re-digitises an image. They're identical for everything else.
DateTime — the file-modification stamp
Tag 0x0132 in the IFD0 (the main TIFF IFD, not the EXIF SubIFD). Originally a TIFF concept: when the file was last saved. Cameras initialise it to the capture time, but every editor that re-saves the file is expected to update it.
So: DateTime later than DateTimeOriginal means the file has been edited and re-saved. DateTime equal to DateTimeOriginal with millisecond precision means the file is straight from the camera. DateTime before DateTimeOriginal is a sign of clock or filesystem fraud — common in copyright-back-dating scenarios.
Subseconds — millisecond precision
The main timestamp fields are second-resolution. EXIF added three companion fields (SubSecTimeOriginal, SubSecTimeDigitized, SubSecTime) carrying the fractional milliseconds as ASCII strings — typically 3 digits, sometimes more. A Sony A7 IV captures at up to 10 fps; without subseconds, ten consecutive shots would all stamp the same instant.
Burst-mode forensics depend on these fields: putting two photos in chronological order requires comparing main-stamp seconds and subsecond strings together. A photo manager that sorts by DateTimeOriginal only will get bursts in upload order, not capture order.
OffsetTimeOriginal — the timezone fix
For 21 years, EXIF stored timestamps in the camera's local time without saying which local. EXIF 2.31 in 2016 finally added OffsetTimeOriginal (0x9011) — an ASCII string like "+02:00" or "-05:00" giving the local UTC offset at capture. Three companion fields cover the digitisation and modification timestamps similarly.
Adoption is uneven. Recent iPhones (iOS 13+) write all three. Modern Sony, Fujifilm, and Nikon bodies write them when the user has set the camera's timezone. Older bodies don't — for those, the timestamps are local-without-zone and you have to infer the zone from GPS or context.
How our viewer presents them
The bundled ExifTool emits each timestamp field as a separate tag (DateTimeOriginal, CreateDate, ModifyDate, the matching SubSecTime* and OffsetTime* companions, and the GPS time tags), and the viewer lists them in the standard searchable table. Comparing them side by side — and spotting a ModifyDate that's later than DateTimeOriginal, or a missing OffsetTime — is the manual job; the viewer doesn't flag conflicts for you.