I hadn’t ’til yesterday realised that EXIF metadata doesn’t actually store dates & times correctly. Whoever came up with the spec all those decades ago clearly didn’t know how to work with dates & times correctly. This is immensely frustrating since now we have countless images taken with timestamps that are collectively gibberish.
The problem is that the standard doesn’t specify time zones in almost all cases (the sole exception being for GPS timestamps, which are in UTC). Which means if you see the date & time “2016-02-03T10:36:33.40” in your photo, that could be any actual time give or take ~25 hours to either side of that.
I realise now, in hindsight, that programs like Aperture & Lightroom manage this by implicitly associating a time zone with photos as they’re imported (and both have controls of varying degrees for ‘correcting’ the time of the photos, in cases where the camera’s clock is set wrong – including being set to the wrong time zone). They leave it to the user to ensure the time zone that’s set for import matches what was on the camera at the time the photos were recorded.
However, if you’re processing images at scale and don’t have that explicit information from the user(s), you’re SOL.
Additionally, I don’t know anyone with a DSLR who hasn’t at least occasionally forgotten to change the date & time on their camera to account for changes in daylight savings time, or movement to a new time zone. If the time zone were recorded, this wouldn’t really matter since you could reliable change it later. But since it’s not, it’s impossible to tell programatically when and where the time zone changes, in a given series of photos.
Now, you might think that since the GPS timestamp is actually recorded as a real, definitive time, that you could just use that to determine the time zone of other dates & times in the metadata (by simply looking at the difference between them). Unfortunately, in this case, the GPS timestamp is defined as the time at which the GPS data was recorded, not when the photo was created (or edited, or any of the other types of timestamps recorded in EXIF metadata). Which means that in practice the GPS timestamp can be an unspecified & unpredictable amount of time older than the other timestamps1.
If it were just a matter of a few minutes difference then this wouldn’t be an issue, since the vast majority of the world only acknowledges half hour increments in time zone steps2 and thus you could just round and get things right most of the time. Unfortunately, at least some notable GPS implementations in popular cameras have potentially huge deltas (hours or more) – e.g. all of Nikon’s SnapBridge cameras, including the D500, D5600, & D3400.
- And that’s assuming the camera’s clock isn’t set wrong anyway – it’s possible to include GPS data in your photos but not sync the camera’s clock, in at least some popular cameras like Nikon’s. ↩︎
- Wikipedia reports that there are a couple of small regions of Australia & New Zealand which use 15 minute offsets, and the entirety of Nepal does too, but those are the only exceptions. And only a small minority use half hour offsets, as opposed to hour offsets, to begin with. ↩︎
