This. Maybe it's from about 1870. Maybe it's Easter, because of the clothes but I only know its before 1940. Maybe it's in august, who knows what day or year. But i scanned it last Tuesday and I played with the image file yesterday. So it now has at least two and probably three or more date-time values, none of which relate to what it is actually "about" in metadata space.
Trying to get exif to handle this kind of random approximation to date is really hard. The systems just don't agree "how". Dublin core has several approaches. They map into EXIF. Kinda.
Google, simply never rescan. If you autoload the image as yesterday, that's its date forever. Change by hand in photos is hard. Microsoft does appear to relearn. Apple? Not sure.
I want to be able to indicate what aspects of a date are real and which ones are estimated or calculated. Or which ones are just missing.
Exiftool supports missing date elements, but only if you have the higher order elements. For example, you can have just the year and month and no day, but you can't have month and no year. See this in the exiftool FAQ: https://exiftool.org/faq.html#Q5
It isn't guaranteed that other tools will know what to do with partial dates either way.
Dublin Core/ISO 8601/Library of Congress has a comprehensive spec for partial dates: https://www.loc.gov/standards/datetime/
While the spec looks good, I haven't seen any solution of saving this as metadata. I'd love to get my hands on some assets that LOC tagged with this spec to see how they log it. There is a python library that supports the extended datetime format, (not for metadata tagging though): https://pypi.org/project/edtf/
I am in the process of scanning and archiving about 20k old family photos from the 1850s to today. My goal is a format to reliably log the metadata in the photo in such a way that it is clear when dates are accurate or guesses.
From what I can tell, the ideal path (aside from everyone agreeing to a standard in metadata) is to not use partial dates in the standard date fields because of compatibility issues. That leaves the only option of using other fields to indicate the status of the date. There are thousands of esoteric potential metadata fields that exiftool can read and write to, but also for compatibility sake, I'd like to stick to standard fields that most tools can at least read.
There are 3 main options I am looking at:
1) Keywords: log the status of the date in a standard keyword format. Something like. "DateStatus: 1950S2" In the edtf from the python library above.
2) Description or Notes field: Use a standard text string in one of these two fields similar to keywords solution above.
3) Use the time aspect of the datetime fields to indicate the status. Come up with a code using the hours, minutes and seconds part of the date to indicate the status of the date field. Something like: if seconds = 22 then year is estimated. This could work seeing as the time of scans is typically not known. (at least in my use case).
From there I need to develop a workflow that allows me to tag the photos with the estimated datetime and then converts that to a sortable datetime in the standard field.
It should support edtf and gedcom format. With some standard rules on how to sort something that is listed as "Circa" or "Before"
I like the idea of edtf or gedcom. Given that the date tags are just specified as "string", if exiftool won't write a partial date, even with the -n option, pick a different tool.
Trying to get exif to handle this kind of random approximation to date is really hard. The systems just don't agree "how". Dublin core has several approaches. They map into EXIF. Kinda.
Google, simply never rescan. If you autoload the image as yesterday, that's its date forever. Change by hand in photos is hard. Microsoft does appear to relearn. Apple? Not sure.