Old photos scanned from paper often have no precise date or time known, but only with precision of a day, a month, or even a year. Strangely, e.g. DateTimeOriginal can only be specified with precision no less than that of a second. digiKam (1.9.0 from Debian testing and 2.6.0rc4 from unstable) doesn’t seem to let me specify a date without time or day or month. I can add a DateTime property with such precision using ExifTool, and digiKam can read and display it in a sidebar, but it cannot use it as the image’s date, e.g. with the Adjust Time & Date feature: it says the source timestamp is missing. Reproducible: Always Steps to Reproduce: 1. Try specifying a date without time, day, or month. 1. Specify such a date directly in the file’s metadata, and try to get digiKam to import it. Actual Results: No luck. Expected Results: Please add support for imprecise dates. At first I didn’t notice that digiKam cannot use DateTime, but apparently the files I tried with had contained a complete date, too.
If i understand your request properly, you want to import image with incomplete date time stamp, typically with time value and only date. If i remember relevant code, when item is imported, we get datetime stamp from metadata and we check if it's valid, typicaly date AND time value are here. Anyway, if you set date as you want and set time to 00:00:00, it's not enough ? Can you share an image with your datetime stamp set in metadata to test in local (if you can attach file to this bugzilla entry) Gilles Caulier
(In reply to comment #1) > Anyway, if you set date as you want and set time to 00:00:00, it's not > enough ? No, sometimes I don’t know the day of month, or even the month (or even the season).
Created attachment 71644 [details] testcase: removed metadata, then ran "ExifTool -DateTime=2005 murka.png"
Apparently both Exif and Xmp support incomplete dates. The data structure which we use, QDateTime, does not. There would be several involved to properly solve this wish: 1) General support - add a QDateTime derived class to libkexiv2 which support incomplete dates 2) Reading - add two methods which properly parse incomplete XMP and Exif date strings as described in the relevant specifications - use these in getImageDateTime 3) Writing - add methods to format incomplete date strings - adapt setImageDateTime 4) check database support, probably need to adapt parsing and formatting 5) Support in digikam's UI 6) Support for writing in the edit widgets
@ Marcel - So when adding a QDateTime derived class to libkexiv2, it must give some default values to the unspecified data. What would be the ideal values for that ? I mean especially for time values, should the default values be in negative ?
I'd expect 1/1 00:00 I'd do it like DateTime : public QDateTime { DateTime(const QDateTime &time) : QDateTime(time) {} } and add one member which defines until which field the data is valid (year, month, day, ...)
Created attachment 72810 [details] Derived class for QDateTime What about this class structure ? Is this okay ?
I would do the extra field with flags: enum ValidFieldFlag { HasYear = 1 << 0, HasMonth = 1 << 1, HasDay = 1 << 2, HasHour = 1 << 3, HasMinute = 1 << 4, HasSecond = 1 << 5, HasMicrosecond = 1 << 6, HasYearOnly = HasYear, HasYearAndMonthOnly = HasYear | HasMonth HasDate = HasYear | HasMonth | HasDay HasTime = HasHour | HasMinute | HasSecond HasDateTime = HasDate | HasTime // ... (+subseconds ...) }; Q_DECLARE_FLAGS(ValidFieldFlags, ValidFieldFlag) // (declare flags operators outside namespace at the bottom) ValidFieldFlags validFieldFlags; // some convenience accessors bool isComplete() { return (validFieldFlags & HasDateTime) == HasDateTime; } etc. // conversion to QDateTime QDateTime toDateTime() const;
Varun, Some progress to write the dedicated class to manage incomplete date in KExiv2 ? Gilles Caulier
This entry is illegible for GSoC 2016 project : https://community.kde.org/GSoC/2016/Ideas#Project:_digiKam_MetadataHub_improvements
> This entry is illegible for GSoC 2016 project : I think you mean “eligible” https://en.wiktionary.org/wiki/eligible , not https://en.wiktionary.org/wiki/illegible
Is there any news about this issue? I am also affected, and before I invest significant time working through my scanned photos to add dates (or having to rework them later when this issue is fixed) I want to decide for the right tool. And I would be sad to work-around it with exiftool instead of staying with digikam. I think the fact that specifications of Exif/Xmp allow incomplete dates is a very strong point that the GUI would better reflect this. If I set the correct incomplete dates with exiftool, can I then later continue using digikam to manage these photos? Suppose I import these photos (with incomplete set by exiftool) into the digikam database, how does it handle these dates? When I update some tags and write them into the image files, will the dates be affected or overwritten?
Answer to the third question: My workflow is now: (0. Remove complete date if previously set in digikam) 1. Set correct incomplete date using exiftool. (See http://owl.phy.queensu.ca/~phil/exiftool/faq.html#Q5) exiftool -xmp:dateTimeOriginal="1980:09" -xmp:CreateDate="1980:09" "image.jpg" 2. Import image file into digikam. Dates are ignored as invalid and not added to database. 3. Add tags to image and write them to image file. Only metadata from database are written to the image file, dates are not affected.
I need to search for a missing EXIF DateTimeOriginal field and there doesn't appear to be a way to do that. Many images do not have a value for that field and being able to search and find those images so the field can be filled in is essential.