Some date formats in the wild do not conform to EXIF standard.
Submitted by Valencia Maintainers
Link to original bug (#712463)
Description
---- Reported by valencia-maint@gnome.bugs 2012-07-09 17:14:00 -0700 ----
Original Redmine bug id: 5524
Original URL: http://redmine.yorba.org/issues/5524
Searchable id: yorba-bug-5524
Original author: Robert Park
Original description:
The attached patch makes the date parsing more robust in Python, adding support for non-standard but apparently common EXIF date strings.
Related issues:
- related to shotwell - http://redmine.yorba.org/show_bug.cgi?id=5560: Move EXIF date handling logic into gexiv2 (Open) related to gexiv2 - Feature #6170: Solidify gexiv2 API (Fixed) related to gexiv2 - http://redmine.yorba.org/show_bug.cgi?id=6741: python {g,s}et_date_time() bindings do not work anymore (Fixed)
---- Additional Comments From valencia-maint@gnome.bugs 2013-10-03 18:20:00 -0700 ----
History
Comment 1
Updated by Jim Nelson over 1 year ago
- Status changed from Open to Review
Comment 2
Updated by Robert Park over 1 year ago
I say 'apparently' because I've never seen these formats myself, but these are the formats supported by pyexiv2, so consider this a case of learning from pyexiv2's experience.
Comment 3
Updated by Jim Nelson over 1 year ago
- Status changed from Review to Open
- Assignee changed from Jim Nelson to Robert Park
We've seen plenty of bogus EXIF date/times in the wild. However, we fixed these in Shotwell rather than gexiv2. (We were fixing them up in Shotwell before we migrated to gexiv2, and the fixup code remained there.)
So, one way to approach this would be to combine the formats there with the formats you have here, so the Python code gets all those as well.
Another approach would be to move this fixup handling into gexiv2 itself, so all callers get the benefit. I'm personally more inclined toward that, although we would need to rope the Shotwell team into the picture to make sure this is done correctly.
Comment 4
Updated by Robert Park over 1 year ago
You're right, having gexiv2 handle it internally so that all callers benefit from it would be the superior solution. Who from the Shotwell team would be best suited to this task? (I have no experience with Shotwell's code).
Comment 5
Updated by Jim Nelson over 1 year ago
I've linked this ticket to a new ticket, #5560, which is to remove the date/time handling logic from Shotwell. This ticket is for adding it into gexiv2.
I've thought about this over weekend and have mixed feelings about how to proceed. gexiv2 is primarily glue logic, designed to make Exiv2 available to GObject-based applications. I don't think gexiv2 should be adding too much fanciness. At the same time, it already has a handful of convenience methods (such as the GPS stuff) which is potentially valuable to a lot of applications. So I think adding this feature is not out of the question.
My other thought is that I don't want gexiv2 to make these bogus dates completely unavailable to the caller. The basic calls (such as gexiv2_metadata_get_exif_tag_string()) should return exactly what Exiv2 reports.
My suggestion is to do something that Shotwell does internally: offer gexiv2_metadata_get_datetime() (as well as EXIF, IPTC, and XMP variants) that returns a GDate object. This method can also do the formatting fix-ups to avoid bogus EXIF date/times.
Comment 6
Updated by Robert Park over 1 year ago
I agree, gexiv2_metadata_get_exif_tag_string
should always return the "raw"
(unaltered) string as it appears in the EXIF. Python syntax like
metadata[tagname]
gets mapped to call get_exif_tag_string
, and I like how
that consistently gives you the raw value, regardless of the chosen tag. So
it's just a matter of making gexiv2_metadata_get_date_time
parse the string
loosely, and then report the string in the canonical EXIF standard format, so
that the Python binding code will understand it without requiring any
modifications (eg, without needing to apply the above patch).
Comment 7
Updated by Robert Park over 1 year ago
Been thinking about this for a bit... since the date handling doesn't seem to be a priority for the Shotwell team, can you just release 0.5 as-is? This issue is relatively minor as far as I'm concerned, and the introspection support is very usable at this point. If you could release 0.5, then my application can finally complete it's Python3 port (waiting for 0.5 is literally the only thing holding me back).
Once 0.5 is out and gets picked up by the distros, then I can start using it, and perhaps other people will start using it too, and once we start getting feedback from other users, that's when we can worry about unifying shotwell/gexiv2's date handling for the benefit of all.
Pretty please? ;-)
Comment 8
Updated by Jim Nelson over 1 year ago
Yorba releases its software on roughly the same cycle as GNOME, i.e. every six months. We plan on releasing 0.5 along with Shotwell 0.13 later this fall. It should be picked up by all the major distros.
Comment 9
Updated by Jim Nelson 11 months ago
- Target version changed from 0.5 to 0.6
Comment 10
Updated by Jim Nelson 11 months ago
- Category set to implementation
Comment 11
Updated by Jim Nelson 8 months ago
- Target version changed from 0.6 to 0.7.0
Comment 12
Updated by Jim Nelson 8 months ago
See #6741 for my thoughts on where this logic could live.
Comment 13
Updated by Jim Nelson about 1 month ago
-
Target version deleted (
<strike>
_0.7.0_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC ---
This bug was previously known as bug 5524 at http://redmine.yorba.org/show_bug.cgi?id=5524 Imported an attachment (id=259984)
Unknown version " in product gexiv2. Setting version to "!unspecified". Unknown milestone "unknown in product gexiv2. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution