Add real_world_date / date_taken field

[warp]

It would be very useful to be able to sort photographs on the date they were taken (which may be different from the date the image file was created).

This will allow users to for example ask for all photographs taken on July 1976.

When users scan pictures or otherwise digitize older media the file creation date will not match the date of the event pictured in the media. This field is about the date of whatever is pictured in the media, and so should be called something like real_world_date, EXIF calls it date_taken.

For files with an EXIF date_taken field, the equivalent mediagoblin database field should get auto-filled when an image is added. Not all media have such a field, so it should be user editable. The EXIF date_taken could also be wrong, so user editable also means the user should be able to clear/delete the date if it was auto-filled.

I discussed this with Elrond (and odinho) on #mediagoblin, 2013-02-18 19:45 UTC.

[Elrond]

I think, we should investigate this after the next release (I doubt we'll get to it for this release). So setting the milestone. (This thing is actionable, so no need to postpone it indefinitely).

Steps needed:

1. Decide on a good sql name for the field. Things like created are not good, because we usually call the "this db record has been created"-dates with that name. date_taken is quite image centric, I think. Need further discussion.
2. Decide on the db representation. We were discussing on "fuzzy dates" (like "sometime in summer 1905").
3. Create the actual field(s).
4. Create logic to fill it from EXIF.
5. Show the date on the media.
6. Add editing possibility on the "edit media" page.
7. Look into further uses (like sorting media according to this field). This probably should be handled in new bugs.

[joar]

Replying to elrond:

1. Decide on a good sql name for the field. Things like created are not good, because we usually call the "this db record has been created"-dates with that name. date_taken is quite image centric, I think. Need further discussion.
2. Decide on the db representation. We were discussing on "fuzzy dates" (like "sometime in summer 1905").

This would fit when searching for photos as it's quite intuitive. It would be kind of hard to store it that way and get a good performance on it compared to a DATETIME I guess.

4. Create logic to fill it from EXIF.

As discovered with the JSON + GstDate issue, it seems that video also may carry this kind of date.

[Elrond]

Related, but different: #532

532 is about showing more exif info.
642 is about having a db field for this stuff.

[Elrond]

To be honest, I doubt we'll get this done for 0.4.0.
We could start. But I doubt we'll finish.