---- 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

####

#1

Updated by Jim Nelson over 1 year ago

  * **Status** changed from _Open_ to _Review_

####

#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.

####

#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.

####

#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).

####

#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.

####

#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).

####

#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? ;-)

####

#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.

####

#9

Updated by Jim Nelson 11 months ago

  * **Target version** changed from _0.5_ to _0.6_

####

#10

Updated by Jim Nelson 11 months ago

  * **Category** set to _implementation_

####

#11

Updated by Jim Nelson 8 months ago

  * **Target version** changed from _0.6_ to _0.7.0_

####

#12

Updated by Jim Nelson 8 months ago

See #6741 for my thoughts on where this logic could live.

####

#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