Prefer `DateTimeOriginal` over `GPSDateTime` for created-at timestamp?
Closed this issue · 3 comments
About a fifth of my photos are showing up in 1970:
sq:/var/lib/photofield/photofield.cache.db=> select count(*) from infos where created_at like '1970%';
count(*)
----------
1865
(1 row)
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:
photofield/internal/image/exiftool-mostlygeek.go
Lines 43 to 54 in d499700
Grabbing one such image for testing:
$ exiftool -S "-SubSecDateTimeOriginal#" "-DateTimeOriginal#" "-EXIF:DateTimeOriginal#" "-CreateDate#" "-XMP:CreateDate#" "-EXIF:CreateDate#" "-XMP:DateTimeOriginal#" "-GPSDateTime#" "-TimeStamp#" "-FileModifyDate#" "-FileCreateDate#" IMG_20180921_184901_1.jpg
SubSecDateTimeOriginal: 2018:09:21 18:49:01.886720
DateTimeOriginal: 2018:09:21 18:49:01
DateTimeOriginal: 2018:09:21 18:49:01
CreateDate: 2018:09:21 18:49:01
CreateDate: 2018:09:21 18:49:01
CreateDate: 2018:09:21 18:49:01
DateTimeOriginal: 2018:09:21 18:49:01
GPSDateTime: 1970:01:18 19:05:52Z
FileModifyDate: 2022:05:03 22:18:37+01:00
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 prefer DateTimeOriginal as the "user-selected" timestamp, as opposed to GPSDateTime 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:
- 2018-09-21 18:45:01 = UNIX timestamp 1537552141
- 1970-01-18 19:05:52 = UNIX timestamp 1537552
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.
Ah interesting! So this logic is kinda tricky, but this is what I have currently:
- Use the first one in that list
- Unless a later one also has an embedded timezone, then use that one. Except if it's file modification or creation date as these usually have timezones, but are less reliable.
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:
- take GPSDateTime if timezone present and not
Z- e.g. GMT as
+00:00, if devices/taggers actually record it that way
- e.g. GMT as
- take DateTimeOriginal and infer timezone from difference with GPSDateTime
- probably want to ensure the difference is a multiple of 15 mins
- see also: Falsehoods programmers believe about time
- take DateTimeOriginal and infer timezone from location
- https://github.com/ringsaturn/tzf looks interesting for this
It 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.