Closed Terrance closed 7 months ago
Ah interesting! So this logic is kinda tricky, but this is what I have currently:
This is so that theoretically we can later display the time of the photo in the timezone it was taken in.
I think here the "Z" in the GPS time implies that it has a timezone (and that timezone is UTC), which makes it take that one as opposed to others. I could remove this timezone logic, but that would lose the advantage of being able to show local time (although I'd need to check if this is even working right now).
Looking at my photos, I can't see any that have a GPSDateTime with a timezone other than Z
, including ones taken in other countries with offsets of a few hours -- this could be specific to my devices, but for me at least it seems like you won't actually get a useful timezone out of here.
Some other possibilities:
Z
+00:00
, if devices/taggers actually record it that wayIt might be that GPSDateTime is just defined to be UTC for most implementations.
Maybe even simpler than the first option, we could just not do the timezone-based override for GPSDateTime specifically. That'll mean it will still be used in case no other preferred time is available, but it won't override DateTimeOriginal.
About a fifth of my photos are showing up in 1970:
The earliest photos I've imported are from 2012, so something's amiss here.
Noting the fields here, which I assume are the ones evaluated for the created-at timestamp:
https://github.com/SmilyOrg/photofield/blob/d49970056c90e131f39e602549e129da34b6ac80/internal/image/exiftool-mostlygeek.go#L43-L54
Grabbing one such image for testing:
GPSDateTime
is in the wrong here, but it seems that was taken as the created date despite it being far down in the list of accepted fields? I think it'd probably make more sense to preferDateTimeOriginal
as the "user-selected" timestamp, as opposed toGPSDateTime
which seems to be a more under-the-hood field (and may not be present if GPS was unavailable?) -- I'm not sure if it's supposed to be preferred currently or not.I'm not sure where these bad values came from, though from throwing the dates into a timestamp converter I can at least see how it went wrong:
Unfortunately digiKam doesn't seem to write the GPS date/time along with the other date fields, so I'll probably need to get my hands dirty with
exiftool
to fix these.